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

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

Browse Source
This commit is contained in:
camperbot
2021-06-29 20:48:10 +05:30
committed by GitHub
parent 4c28a9be5e
commit fc90c869a2
20 changed files with 4277 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
docs/i18n/italian/FAQ.md Normal file
View File

@ -0,0 +1,87 @@
### Sono nuovo in GitHub e nel mondo Open Source. Da dove dovrei iniziare?
Leggi la nostra guida ["Come contribuire all'Open Source"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). E' un compendio completo per progetti adatti a neofiti. Ed essa include un sacco di consigli per contribuire all'open source.
### Posso tradurre le risorse di freeCodeCamp?
Sì, puoi contribuire a ognuna delle oltre 30 lingue abilitate sulla nostra piattaforma di traduzione.
Abbiamo già live le traduzioni fatte dagli utenti per cinese (中文), spagnolo (Español) e italiano. Abbiamo intenzione di localizzare freeCodeCamp nelle lingue più usate nel mondo. Puoi leggere tutto su questo argomento nel nostro [annuncio](https://www.freecodecamp.org/news/world-language-translation-effort).
Se sei interessato a contribuire alla traduzione per favore assicurati di [leggere questa guida](/how-to-translate-files) come prima cosa.
### Come posso segnalare un nuovo bug?
Se pensi di avere trovato un bug, prima leggi l'articolo ["Help I've Found a Bug" (Aiuto ho trovato un bug)](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) e segui le istruzioni.
Se sei certo che sia un nuovo bug, vai avanti e crea una issue su GitHub. Assicurati di includere quante più informazioni possibili in modo che sia possibile riprodurre il bug. Abbiamo un template predefinito per quando si crea un'issue per aiutarti in questo.
Per favore nota che queste issue in GitHub sono per problemi e discussioni sulla codebase, non per chiedere aiuto mentre impari a programmare. Se hai dubbi, dovresti [chiedere assistenza sul forum](https://forum.freecodecamp.org) prima di creare un'issue su GitHub.
### Come posso segnalare un problema di sicurezza?
Per favore non creare issue su GitHub per problemi di sicurezza. Invece invia una email a `security@freecodecamp.org` e controlleremo immediatamente.
### Io sono uno studente. Posso lavorare su una caratteristica ottenendo crediti accademici?
Sì. Per favore nota che non siamo in grado di impegnarci in alcun modo per limiti di tempo o questioni burocratiche che possono essere richiesti dal tuo college o dalla tua università. Riceviamo molte pull request e contributi al codice da sviluppatori volontari, e rispettiamo il loro tempo e i loro sforzi. Per rispetto di tutti gli altri nostri contributori, non daremo ad alcuna PR priorità speciale solo perché è legata a impegni accademici.
Ti chiediamo di pianificare in anticipo e lavorare sui contributi al codice tenendolo a mente.
### Cosa significano queste diverse etichette che vengono associate ai problemi?
I manutentori del codice [smistano](https://en.wikipedia.org/wiki/Software_bug#Bug_management) issue e pull request a seconda della loro priorità, gravità e altri fattori. Puoi trovare [un glossario dei loro significati qui.](https://github.com/freecodecamp/freecodecamp/labels).
### Da dove comincio se voglio lavorare su un problema?
Dovresti guardare le issue taggate con [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) o [**`first timers only`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) per una veloce overview di cosa è disponibile per lavorarci su.
> [!TIP] Le issue **`help wanted`** sono a disposizione, e non devi chiedere permessi per poterci lavorare. Tuttavia, le issue con l'etichetta **`first timers only`** sono problemi speciali che sono stati progettati per le persone che non hanno contribuito al codice freeCodeCamp prima d'ora.
### Ho trovato un errore di ortografia. Dovrei creare un'issue prima di poter fare una pull request?
Per errori di ortografia e altre modifiche di parole, puoi aprire direttamente una pull request senza prima creare un'issue. Per favore assicurati di scrivere dettagli nella descrizione della pull request per aiutarci a capire e rivedere il tuo contributo, anche se è un piccolo cambiamento.
Per favore crea un'issue se vuoi discutere aspetti più ampi del codebase o del curriculum.
### Come posso farmi assegnare un'issue?
In genere non assegnamo issue se non a contributori esperti. Invece, seguiamo la seguente politica per essere giusti nei confronti di tutti:
1. Abbiamo maggiori probabilità di fare il merge della prima pull request che affronta il problema.
2. Nel caso di più contributori che aprono una pull request per lo stesso problema all'incirca allo stesso tempo, daremo la priorità alla pull request che affronta al meglio la questione. Alcune delle cose che consideriamo:
- Hai incluso dei test?
- Hai coperto tutti i casi d'uso?
- Ti sei assicurato che tutti i test siano superati, e confermi che tutto funziona localmente?
3. Infine, diamo la priorità alle pull request che seguono le nostre linee guida raccomandate.
- Hai seguito la checklist delle pull request?
- Hai dato alla tua pull request un titolo significativo?
### Sono bloccato su qualcosa che non è incluso in questa documentazione.
**Se hai bisogno chiedi liberamente aiuto in:**
- La categoria `Contributors` del [forum della nostra community](https://forum.freecodecamp.org/c/contributors).
- Il canale `#Contributors` sul nostro [chat server](https://chat.freecodecamp.org/channel/contributors).
Siamo entusiasti di aiutarti a contribuire in ognuno degli ambiti su cui vorresti lavorare. Se fai domande sul relativo thread di un'issue, saremo lieti di rispondere. Assicurati di fare una ricerca per la tua domanda prima di porne una nuova.
Ti ringraziamo in anticipo per essere educato e paziente. Ricordati che questa comunità è gestita principalmente da volontari.
### Assistenza aggiuntiva
Se hai domande sul nostro stack, sull'architettura del codebase, traduzioni, o qualsiasi altra cosa, rivolgiti liberamente al nostro staff.
| Staff | Invia un messaggio nel Forum |
|:--------------------- |:---------------------------------------------------------------------------- |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Miya Liu | [@miyaliu](https://chinese.freecodecamp.org/forum/u/miyaliu) |
| Mrugesh Mohapatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Nicholas Carrigan | [@nhcarrigan](https://forum.freecodecamp.org/u/nhcarrigan) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Rafael D Hernandez | [@RafaelHernandez](https://forum.freecodecamp.org/u/rafaelhernandez) |
| Shaun Hamilton | [@sky020](https://forum.freecodecamp.org/u/sky020) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
**Puoi scrivere una mail allo staff di sviluppo a: `dev[at]freecodecamp.org`**

33
docs/i18n/italian/_sidebar.md Normal file
View File

@ -0,0 +1,33 @@
- **Per iniziare**
- [Introduzione](index.md "Contribuire alla comunità freeCodeCamp.org")
- [Domande frequenti](FAQ.md)
- **Contribuire al codice**
- [Imposta freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md)
- [Aprire una pull request](how-to-open-a-pull-request.md)
- [Lavorare sulle sfide di programmazione](how-to-work-on-coding-challenges.md)
- [Lavorare sulle sfide video](how-to-help-with-video-challenges.md)
- [Lavorare sul tema delle news](how-to-work-on-the-news-theme.md)
- [Lavorare sul tema della documentazione](how-to-work-on-the-docs-theme.md)
- [Lavorare sui progetti di pratica](how-to-work-on-practice-projects.md)
- **Contribuire alla traduzione**
- [Lavorare a tradurre le risorse](how-to-translate-files.md)
- [Lavorare a correggere le risorse](how-to-proofread-files.md)
- **Guide opzionali**
- [Settare freeCodeCamp su Windows (WSL)](how-to-setup-wsl.md)
- [Aggiungere test Cypress](how-to-add-cypress-tests.md)
- [Lavorare sulla app web in locale](how-to-work-on-localized-client-webapp.md)
- [Intercettare email in uscita localmente](how-to-catch-outgoing-emails-locally.md)
- [Testare traduzioni in locale](how-to-test-translations-locally.md)
---
- **Manuali di volo** (per membri dello staff & moderatori)
- [Manuale del moderatore](moderator-handbook.md)
- [Manuale DevOps](devops.md)
---
- **La nostra comunità**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Forum su Discourse**](https://freecodecamp.org/forum/c/contributors)
- [**Server per chattare**](https://chat.freecodecamp.org/home)

919
docs/i18n/italian/devops.md Normal file
View File

@ -0,0 +1,919 @@
# Manuale di DevOps
Questa guida ti aiuterà a capire lo stack della nostra infrastruttura e come gestiamo le nostre piattaforme. Anche se questa guida non ha dettagli esaustivi per tutte le operazioni, può essere utilizzata come riferimento per la comprensione dei sistemi.
Facci sapere se hai commenti o domande, e saremo felici di darti ulteriori chiarimenti.
# Manuale di volo - Deployment del codice
Questo repository è continuamente sottoposto a build, test e deployment su **set separati di infrastrutture (Servers, Databases, CDN, ecc.)**.
Questo prevede tre fasi da seguire in sequenza:
1. I nuovi cambiamenti (sia risoluzioni di bug che nuove caratteristiche) sono aggiunti al branch principale di sviluppo (`main`) tramite pull requests.
2. Queste modifiche sono testate da una serie di test automatizzati.
3. Una volta che i test sono superati, rilasciamo le modifiche (o aggiornamenti se necessario) alle distribuzioni sulla nostra infrastruttura.
#### Costruire il codebase - Mappare i branch di Git alle distribuzioni.
In genere, si fa un merge di [`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) (il ramo di sviluppo di default) nel branch [`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) una volta al giorno, e questo è rilasciato in una infrastruttura isolata.
Questa è una release intermedia per i nostri sviluppatori e collaboratori volontari. È anche noto come il nostro rilascio di "staging" o "beta".
È identico al nostro ambiente di produzione live su `freeCodeCamp.org`, a parte il fatto che utilizza un set separato di database, server, web-proxies, ecc. Questo isolamento ci permette di testare lo sviluppo continuo e le caratteristiche in uno scenario come quello di "produzione", senza influenzare gli utenti regolari delle principali piattaforme di freeCodeCamp.org.
Una volta che il team di sviluppo [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) è soddisfatto dei cambiamenti nella piattaforma di staging, questi cambiamenti sono spostati ogni pochi giorni al branch [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-current).
Questa è la versione finale che sposta le modifiche alle nostre piattaforme di produzione su freeCodeCamp.org.
#### Testare le modifiche - Integrazione e Test di accettazione dell'utente.
Adottiamo vari livelli di integrazione e test di accettazione per verificare la qualità del codice. Tutti i nostri test sono fatti con software come [GitHub Actions CI](https://github.com/freeCodeCamp/freeCodeCamp/actions) e [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
Abbiamo test unitari per testare le nostre soluzioni delle sfide, API dei server e interfacce utente del client. Questi ci aiutano a testare l'integrazione tra i diversi componenti.
> [!NOTE] Siamo anche in fase di scrittura di test utente finale che ci aiuteranno a replicare scenari del mondo reale come l'aggiornamento di una e-mail o una chiamata all'API o a servizi di terze parti.
Tutti questi test aiutano a evitare che i problemi si ripetano e assicurano di non introdurre dei bug mentre si lavora su un altro bug o una nuova funzionalità.
#### Deploy delle modifiche - Push delle modifiche ai server.
Abbiamo configurato un software di consegna continua per inviare modifiche ai nostri server di sviluppo e produzione.
Una volta che le modifiche sono inviate ai branch di rilascio protetti, una pipeline di build viene attivata automaticamente per il branch. Le pipeline di build sono responsabili della compilazione degli artefatti e di conservarli in un deposito di stoccaggio per un uso successivo.
La pipeline di build continua ad attivare una corrispondente pipeline di rilascio se completa un'esecuzione riuscita. Le pipeline di rilascio sono responsabili della raccolta degli artefatti di build, e di spostarli sui server di produzione.
Lo stato delle build e delle release è [disponibile qui](#build-test-and-deployment-status).
## Avviare un build, test e deploy
Attualmente, solo i membri del team di sviluppo possono fare il push sui branch di produzione. Le modifiche ai branch `production-*` possono avvenire solo tramite il merge fast-forward all'[`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!NOTE] Nei prossimi giorni miglioreremmo questo flusso in modo che avvenga tramite pull-requests, per una migliore gestione degli accessi e della trasparenza.
### Invio delle modifiche alle applicazioni in staging.
1. Configura correttamente i tuoi remotes.
```sh
git remote -v
```
**Risultati:**
```
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Assicurati che il tuo branch `main` sia pulito e sincronizzato con la fonte (upstream).
```sh
git checkout main
git fetch --all --prune
git reset --hard upstream/main
```
3. Controlla che i test GitHub CI siano superati nel branch `main` dell'upstream.
I test di [integrazione continua](https://github.com/freeCodeCamp/freeCodeCamp/actions) dovrebbero essere verdi ed essere superati per il branch `main`. Clicca sulla spunta verde vicino all'hash del commit guardando il codice del branch `main`.
<details> <summary> Controllare lo stato sulle GitHub Actions (screenshot) </summary>
<br>
![Controllare lo stato sulle GitHub Actions](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/devops/github-actions.png)
</details>
Se questo fallisce, dovresti fermarti e investigare gli errori.
4. Conferma di essere in grado di fare il build del repository localmente.
```
npm run clean-and-develop
```
5. Sposta cambiamenti da `main` a `prod-staging` con un merge fast-forward
```
git checkout prod-staging
git merge main
git push upstream
```
> [!NOTE] Non sarai in grado di forzare il push e se hai riscritto la cronologia in ogni caso questi comandi restituiranno degli errori.
>
> Se lo fanno, potresti aver fatto qualcosa in modo errato e dovresti solo ricominciare da capo.
Gli step precedenti attiveranno automaticamente l'esecuzione della pipeline di build per il ramo `prod-staging`. Una volta completata la build, gli artefatti vengono salvati come file `.zip` in un archivio per essere recuperati e utilizzati in seguito.
La pipeline di rilascio viene attivata automaticamente quando un nuovo artefatto è disponibile dalla pipeline di build connessa. Per le piattaforme di staging questo processo non comporta l'approvazione manuale e gli artefatti vengono inviati alla CDN client e ai server API.
### Inviare le modifiche alle applicazioni in produzione.
Il processo è per lo più lo stesso delle piattaforme di staging, con la messa in atto di alcuni controlli aggiuntivi. Questo è solo per essere sicuri: non possiamo permetterci di rompere nulla su freeCodeCamp.org dato che può vedere centinaia di utenti che lo utilizzano in qualsiasi momento.
| NON eseguire questi comandi a meno che non sia stato verificato che tutto funziona sulla piattaforma di staging. Non dovresti bypassare o saltare alcun test di staging prima di procedere ulteriormente. |
|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
1. Assicurati che il tuo ramo `prod-staging` sia pulito e sincronizzato con la fonte.
```sh
git checkout prod-staging
git fetch --all --prune
git reset --hard upstream/prod-staging
```
2. Sposta cambiamenti da `prod-staging` a `prod-current` con un merge fast-forward
```
git checkout prod-current
git merge prod-staging
git push upstream
```
> [!NOTE] Non sarai in grado di forzare il push e se hai riscritto la cronologia in ogni caso questi comandi restituiranno degli errori.
>
> Se lo fanno, potresti aver fatto qualcosa in modo errato e dovresti solo ricominciare da capo.
Gli step precedenti attiveranno automaticamente l'esecuzione della pipeline di build per il ramo `prod-current`. Una volta che un artefatto di build è pronto, attiverà un avvio della pipeline di rilascio.
**Misure supplementari per le azioni dello Staff**
Una volta che viene avviato un processo di rilascio, i membri del team dello staff di sviluppo riceveranno un'e-mail automatizzata di intervento manuale. Possono _approvare_ o _rifiutare_ l'esecuzione del rilascio.
Se le modifiche funzionano bene e sono state testate sulla piattaforma di staging, allora possono essere approvate. L’approvazione deve essere rilasciata entro 4 ore dall’attivazione del rilascio prima di essere respinta automaticamente. Un membro dello staff può riattivare il rilascio manualmente per gli avvi rifiutati, o attendere il prossimo ciclo di rilascio.
Per uso dello staff:
| Controlla la tua email per un link diretto o [vai alla dashboard di rilascio](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) dopo che la build è completata. |
|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
Una volta che uno dei membri dello staff approva una release, la pipeline porterà i cambiamenti live ai CDN di produzione e ai server API di freecodecamp.org.
## Stato di build, test e distribuzione
Ecco lo stato attuale di test, build e deployment del codebase.
| Ramo | Test unitari | Test di integrazione | Build & rilasci |
|:-------------------------------------------------------------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |:--------------------------------------------------------------------------------------------------------------------------------- |
| [`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) | [![Node.js CI](https://github.com/freeCodeCamp/freeCodeCamp/workflows/Node.js%20CI/badge.svg?branch=main)](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22) | [![Cypress E2E Tests](https://img.shields.io/endpoint?url=https://dashboard.cypress.io/badge/simple/ke77ns/main&style=flat&logo=cypress)](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | - |
| [`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) | [![Node.js CI](https://github.com/freeCodeCamp/freeCodeCamp/workflows/Node.js%20CI/badge.svg?branch=prod-staging)](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22+branch%3Aprod-staging) | [![Cypress E2E Tests](https://img.shields.io/endpoint?url=https://dashboard.cypress.io/badge/simple/ke77ns/prod-staging&style=flat&logo=cypress)](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_dashboards/dashboard/d59f36b9-434a-482d-8dbd-d006b71713d4) |
| [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) | [![Node.js CI](https://github.com/freeCodeCamp/freeCodeCamp/workflows/Node.js%20CI/badge.svg?branch=prod-current)](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22+branch%3Aprod-current) | [![Cypress E2E Tests](https://img.shields.io/endpoint?url=https://dashboard.cypress.io/badge/simple/ke77ns/prod-current&style=flat&logo=cypress)](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_dashboards/dashboard/d59f36b9-434a-482d-8dbd-d006b71713d4) |
| `prod-next` (sperimentale, futuro) | - | - | - |
## Early access e beta test
Ti diamo il benvenuto al test di queste versioni in modalità **"public beta testing"** e all'accesso anticipato alle funzionalità imminenti delle piattaforme. A volte queste funzionalità/modifiche sono indicate come **next, beta, staging,** ecc. in modo intercambiabile.
I tuoi contributi tramite feedback e segnalazioni di problemi ci aiuteranno a rendere le piattaforme di produzione su `freeCodeCamp.org` più **robuste**, **consistenti** e **stabili** per tutti.
Ti ringraziamo se vorrai segnalare i bug che incontrerai aiutandoci a migliorare freeCodeCamp.org. Sei un grande!
### Identificare la prossima versione delle piattaforme
Attualmente una versione beta test pubblica è disponibile al seguente indirizzo:
| Applicazione | Lingua | URL |
|:------------ |:-------- |:---------------------------------------- |
| Learn | Inglese | <https://www.freecodecamp.dev> |
| | Spagnolo | <https://www.freecodecamp.dev/espanol> |
| | Cinese | <https://chinese.freecodecamp.dev> |
| News | Inglese | <https://www.freecodecamp.dev/news> |
| Forum | Inglese | <https://forum.freecodecamp.dev> |
| | Cinese | <https://chinese.freecodecamp.dev/forum> |
| API | - | `https://api.freecodecamp.dev` |
> [!NOTE] Il nome del dominio è diverso da **`freeCodeCamp.org`**. Questo è intenzionale per prevenire l'indicizzazione dai motori di ricerca e creare confusione per i normali utenti della piattaforma.
>
> La lista precedende non è esaustiva di tutte le applicazioni che offriamo. E non tutte le varie lingue sono rilasciate in staging per risparmiare risorse.
### Identificare la versione attuale delle piattaforme
**La versione attuale della piattaforma è sempre disponibile su [`freeCodeCamp.org`](https://www.freecodecamp.org).**
Il team di sviluppo fa un merge dei cambiamenti dal ramo `prod-staging` a `prod-current` quando rilascia dei cambiamenti. Il commit superiore dovrebbe essere quello che si vede live sul sito.
È possibile identificare la versione esatta distribuita visitando i registri di compilazione e distribuzione disponibili nella sezione stato. In alternativa puoi scriverci nella [chat room dei contributori](https://chat.freecodecamp.org/channel/contributors) per una conferma.
### Limitazioni note
Ci sono alcune limitazioni e compromessi noti quando si utilizza la versione beta della piattaforma.
- #### Tutti i dati / progressi personali su queste piattaforme beta `NON saranno salvati o riportati` alla produzione.
**Gli utenti nella versione beta avranno un account separato dalla produzione.** La versione beta utilizza un database fisicamente separato dalla produzione. Questo ci dà la possibilità di prevenire qualsiasi perdita accidentale di dati o modifiche. Il team di sviluppo può eliminare il database su questa versione beta se necessario.
- #### Non ci sono garanzie sull'uptime e l'affidabilità delle piattaforme beta.
Il deploy dovrebbe essere frequente e in iterazioni rapide, talvolta più volte al giorno. Di conseguenza a volte ci saranno tempi di inattività inattesi o funzionalità guaste sulla versione beta.
- #### Non inviare utenti regolari a questo sito come misura per confermare una correzione
Il sito beta ha il solo scopo di supportare lo sviluppo locale e il testing, nient'altro. Non è una promessa di ciò che sta arrivando, ma un assaggio di ciò a cui si sta lavorando.
- #### La pagina di iscrizione può essere diversa da quella di produzione
Usiamo un test tenant per freeCodeCamp.dev su Auth0, e quindi non abbiamo l'abilità di impostare un dominio personalizzato. Questo fa sì che tutte le callback di reindirizzamento e la pagina di login appaiano su un dominio predefinito come: `https://freecodecamp-dev.auth0.com/`. Questo non ha effetto sulle funzionalità ed è quanto più vicino possiamo arrivare alla produzione.
## Segnalazione di problemi e invio di feedback
Per favore apri nuove issue per discutere e segnalare bug.
Puoi inviare un'email a `dev[at]freecodecamp.org` se hai domande. Come sempre tutte le vulnerabilità di sicurezza dovrebbero essere segnalate a `security[at]freecodecamp.org` invece che al tracker pubblico o nel forum.
# Manuale di volo - Manutenzione del sever
> [!WARNING]
>
> 1. Questa guida è rivolta solo ai **membri dello staff di freeCodeCamp**.
> 2. Queste istruzioni non devono essere considerate esaustive, per favore usa cautela.
Come membro dello staff, potrebbe esserti stato dato accesso ai nostri fornitori di servizi cloud come Azure, Digital Ocean, ecc.
Ecco alcuni utili comandi che puoi usare per lavorare sulle Virtual Machine (VM), per fare manutenzione o faccende generali.
## Ottieni una lista delle VM
> [!NOTE] Anche se puoi già avere avere accesso SSH alle VM, questo da solo non ti permetterà di avere l'elenco delle VM a meno che non ti sia stato concesso l'accesso ai portali cloud.
### Azure
Installa Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(Una volta sola) Installa su macOS con [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(Una volta sola) Login:**
```
az login
```
> **Ottieni una lista dei nomi delle VM e degli indirizzi IP:**
```
az vm list-ip-addresses --output table
```
### Digital Ocean
Installa Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One volta sola) Installa su macOS con [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(Una Volta) Login:**
Autenticazione e cambio di contesto: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Ottieni una lista dei nomi delle VM e degli indirizzi IP:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
## Creare nuove risorse
Stiamo lavorando per creare il nostro setup IaC, e mentre stiamo lavorando su quello puoi usare il portale di Azure o il CLI di Azure per creare nuove macchine virtuali e altre risorse.
> [!TIP] Non importa cosa usi per creare nuove risorse, abbiamo alcuni [utili file di configurazione cloud-init](https://github.com/freeCodeCamp/infra/tree/main/cloud-init) per aiutarti a fare provisioning di base, come installare docker o aggiungere le chiavi SSH, ecc.
## Mantieni le VM aggiornate
Dovresti tenere aggiornate le VM eseguendo update e upgrade. Questo assicurerà che la macchina virtuale sia patchata con le ultime correzioni di sicurezza.
> [!WARNING] Prima di eseguire questi comandi:
>
> - Assicurati che il provisioning della VM sia stato completato e che non ci siano step post-install in esecuzione.
> - Se stai aggiornando pacchetti su una VM che sta già servendo una applicazione, assicurati che l'app sia stata fermata e salvata. L'aggiornamento dei pacchetti causerà picchi di utilizzo di banda, memoria e/o CPU portando a malfunzionamenti di applicazioni in esecuzione.
Aggiorna informazioni sul pacchetto
```console
sudo apt update
```
Aggiorna i pacchetti installati
```console
sudo apt upgrade -y
```
Pulisci i pacchetti inutilizzati
```console
sudo apt autoremove -y
```
## Lavora sui server Web (Proxy)
Stiamo eseguendo istanze di carico bilanciate (Azure Load Balancer) per i nostri server web. Questi server eseguono NGINX che inverte il proxy di tutto il traffico a freeCodeCamp.org da varie applicazioni in esecuzione sulle proprie infrastrutture.
La configurazione di NGINX è disponibile su [questo repository](https://github.com/freeCodeCamp/nginx-config).
### Prima Installazione
Provisioning delle VM con il codice
1. Installa NGINX e configuralo dal repository.
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
2. Installa i certificati di origine di Cloudfire e la configurazione dell'applicazione di upstream.
Ottieni il certificati di origine di Cloudflare dallo storage sicuro e installa nelle posizioni richieste.
**O**
Sposta i certificati esistenti:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Aggiorna le configurazioni di upstream:
```console
vi configs/upstreams.conf
```
Aggiungi/aggiorna gli indirizzi IP di sorgente/origine dell'applicazione.
3. Fai il setup di network e firewall.
Configura i firewall di Azure e `ufw` come necessario per indirizzi di origine d'ingresso.
4. Aggiungi la VM al pool del load balancer del backend.
Configura e aggiungi regole al load balancer se necessario. Potresti anche aver bisogno di aggiungere le VM al pool del load balancer del backend.
### Aggiornamento Istanze (Manutenzione)
1. Controlla lo stato dei servizi NGINX usando i comandi seguenti:
```console
sudo systemctl status nginx
```
2. I log e il monitoraggio dei server sono disponibili su:
NGINX Amplify: [https://amplify.nginx.com]('https://amplify.nginx.com'), l'attuale dashboard per il monitoraggio. Stiamo lavorando a metriche più granulari per una osservabilità migliore
### Aggiornamento Istanze (Manutenzione)
Le modifiche di configurazione alle nostre istanze NGINX sono mantenute su GitHub, queste dovrebbero essere distribuite su ogni istanza in questo modo:
1. SSH nell'istanza e inserisci sudo
```console
sudo su
```
2. Ottieni l'ultimo codice di configurazione.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/main
```
3. Prova e ricarica la configurazione [con i segnali](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
## Lavora sulle istanze API
1. Installa strumenti di generazione per i binari di node (`node-gyp`) ecc.
```console
sudo apt install build-essential
```
### Prima Installazione
Fare il provisioning delle VM con il codice
1. Installare Node LTS.
2. Aggiorna `npm` e installa PM2 e fai il setup di `logrotate` e avvio all'accensione
```console
npm i -g npm@6
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clona freeCodeCamp, setup env e chiavi.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout prod-current # or any other branch to be deployed
```
4. Crea il `.env` dalla memorizzazione sicura delle credenziali.
5. Crea `google-credentials.json` dall'archivio sicuro delle credenziali.
6. Installa dipendenze
```console
npm ci
```
7. Fai il build del server
```console
npm run ensure-env && npm run build:curriculum && npm run build:server
```
8. Avvia le istanze
```console
cd api-server
pm2 start ./lib/production-start.js -i max --max-memory-restart 600M --name org
```
### Log e monitoraggio
```console
pm2 logs
```
```console
pm2 monit
```
### Aggiornamento Istanze (Manutenzione)
Ogni tanto devono essere fatti dei deployment dei cambiamenti al codice alle istanze delle API. Può essere un update continuo o un update manuale. Il secondo è essenziane quando si cambiando dipendenze o si aggiungono variabili d'ambiente.
> [!ATTENTION] Le pipeline automatizzate al momento non gestiscono l'aggiornamento delle dipendenze. Dobbiamo fare un aggiornamento manuale prima dell'avvio di qualsiasi pipeline di deployment.
#### 1. Aggiornamenti manuali - Usati per aggiornare dipendenze, variabili env.
1. Ferma tutte le istanze
```console
pm2 stop all
```
2. Installa dipendenze
```console
npm ci
```
3. Fai il build del server
```console
npm run ensure-env && npm run build:curriculum && npm run build:server
```
4. Avvia le istanze
```console
pm2 start all --update-env && pm2 logs
```
#### 2. Aggiornamenti continui - usati per cambiamenti logici al codice.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] Gli update continui a codice e logica sono gestiti dalle pipeline. Non dovresti aver bisogno di eseguire questi comandi. Sono qui per documentazione.
## Lavora sulle istanze del client
1. Installa strumenti di generazione per i binari di node (`node-gyp`) ecc.
```console
sudo apt install build-essential
```
### Prima Installazione
Fare provisioning delle VM con il codice
1. Installare Node LTS.
2. Aggiorna `npm` e installa PM2 e fai il setup di `logrotate` e avvio all'accensione
```console
npm i -g npm@6
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clona la configurazione del client, l'env di configurazione e le chiavi.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Avvia le istanze placeholder per il web client, queste verranno aggiornate con artefatti dalla pipeline Azure.
> Todo: questo setup deve essere spostato a S3 o Azure Blob storage
>
> ```console
> echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
> chmod +x client-start-primary.sh
> pm2 delete client-primary
> pm2 start ./client-start-primary.sh --name client-primary
> echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
> chmod +x client-start-secondary.sh
> pm2 delete client-secondary
> pm2 start ./client-start-secondary.sh --name client-secondary
> ```
### Aggiornamento Istanze (Manutenzione)
```console
pm2 logs
```
```console
pm2 monit
```
### Aggiornamento Istanze (Manutenzione)
Ogni tanto devono essere fatti dei deployment dei cambiamenti al codice alle istanze delle API. Può essere un update continuo o un update manuale. Il secondo è essenziane quando si cambiando dipendenze o si aggiungono variabili ambientali.
> [!ATTENTION] Le pipeline automatizzate al momento non gestiscono l'aggiornamento delle dipendenze. Dobbiamo fare un aggiornamento manuale prima di ogni esecuzione della pipeline di deployment.
#### 1. Aggiornamenti manuali - Usati per aggiornare dipendenze, variabili env.
1. Ferma tutte le istanze
```console
pm2 stop all
```
2. Installa o aggiorna le dipendenze
3. Avvia le istanze
```console
pm2 start all --update-env && pm2 logs
```
#### 2. Aggiornamenti continui - usati per cambiamenti logici al codice.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] Gli update continui a codice e logica sono gestiti dalle pipeline. Non dovresti aver bisogno di eseguire questi comandi. Sono qui per documentazione.
## Lavorare sui server di chat
I nostri chat server sono disponibili con una configuratione HA [raccomandata nella documentazione di Rocket.Chat](https://docs.rocket.chat/installation/docker-containers/high-availability-install). Il file `docker-compose` per questo è [disponibile qui](https://github.com/freeCodeCamp/chat-config).
Avviamo istanze ridondanti di NGINX che sono loro stesse con bilanciamento di carico (Azure Load Balancer) sul cluster di Rocket.Chat. I file di configurazione NGINX sono [disponibili qui](https://github.com/freeCodeCamp/chat-nginx-config).
### Prima installazione
Fare provisioning delle VM con il codice
**Cluster NGINX:**
1. Installa NGINX e configuralo dal repository.
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/chat-nginx-config nginx
cd /etc/nginx
```
2. Installa i certificati di origine di Cloudflare e la configurazione dell'applicazione di upstream.
Ottieni il certificati di origine di Cloudflare dallo storage sicuro e installa nelle posizioni richieste.
**O**
Sposta i certificati esistenti:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Aggiorna le configurazioni di upstream:
```console
vi configs/upstreams.conf
```
Aggiungi/aggiorna gli indirizzi IP source/origin dell'applicazione.
3. Fai il setup di network e firewall.
Configura i firewall di Azure e `ufw` come necessario per indirizzi di origine d'ingresso.
4. Aggiungi la VM al pool del load balancer del backend.
Configura e aggiungi regole al load balancer se necessario. Potresti anche aver bisogno di aggiungere le VM al pool del load balancer del backend.
**Cluster Docker:**
1. Installa Docker e configura dal repository
```console
git clone https://github.com/freeCodeCamp/chat-config.git chat
cd chat
```
2. Configura le variabili d'ambiente (env) richieste e gli indirizzi IP delle istanze.
3. Avvia il server rocket-chat
```console
docker-compose config
docker-compose up -d
```
### Logging e monitoraggio
1. Controlla lo stato dei servizi NGINX usando i comandi seguenti:
```console
sudo systemctl status nginx
```
2. Controlla lo stato delle istanze docker in esecuzione con:
```console
docker ps
```
### Aggiornamento istanze (Manutenzione)
**Cluster NGINX:**
Le modifiche di configurazione alle nostre istanze NGINX sono mantenute su GitHub, queste dovrebbero essere distribuite su ogni istanza in questo modo:
1. SSH nell'istanza ed entra con sudo
```console
sudo su
```
2. Ottieni il codice di configurazione più recente.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/main
```
3. Testa e ricarica la configurazione [con Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
**Cluster Docker:**
1. SSH nell'istanza e naviga al percorso di configurazione della chat
```console
cd ~/chat
```
2. Ottieni il codice di configurazione più recente.
```console
git fetch --all --prune
git reset --hard origin/main
```
3. Ottieni l'immagine docker più recente da Rocket.Chat
```console
docker-compose pull
```
4. Aggiorna le istanze in esecuzione
```console
docker-compose up -d
```
5. Verifica che le istanze siano in funzione
```console
docker ps
```
6. Pulisci risorse estranee
```console
docker system prune --volumes
```
Output:
```console
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all volumes not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N] y
```
Seleziona yes (y) per rimuovere tutto quello che non è in uso. Questo rimuoverà tutti i contenitori che sono stati arrestati, tutti i network e volumi che non sono utilizzati da almeno un container, e le cache di immagini e build scollegate.
## Aggiornare la versione di Node.js sulle VM
Visualizza le versioni installate di node & npm
```console
nvm -v
node -v
npm -v
nvm ls
```
Installa l'ultima versione di Node.js LTC, e reinstalla i pacchetti globali
```console
nvm install 'lts/*' --reinstall-packages-from=default
```
Verifica i pacchetti installati
```console
npm ls -g --depth=0
```
Usa l'alias `default` della versione di Node.js all'attuale LTS
```console
nvm alias default lts/*
```
(Facoltativo) Disinstalla vecchie versioni
```console
nvm uninstall <version>
```
> [!WARNING] Se usi PM2 per i processi avrai anche bisogno di vedere le applicazioni e salvare la lista dei processi per il recovery automatico al riavvio.
Comandi veloci per PM2 per elencare, far ripartire processi salvati, ecc.
```console
pm2 ls
```
```console
pm2 resurrect
```
```console
pm2 save
```
```console
pm2 logs
```
> [!ATTENTION] Per applicazioni client, lo script della shell non può essere fatto risorgere tra versioni di Node.js con `pm2 resurrect`. Fai il deploy dei processi da zero. Questo dovrebbe migliorare quando useremo un setup basato su docker.
## Installare e aggiornare Azure Pipeline Agent
Vedi: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops e segui le istruzioni per arrestare, rimuovere e reinstallare gli agenti. Approssimativamente puoi seguire gli step elencati qui.
Avrai bisogno di un PAT, che puoi ottenere da: https://dev.azure.com/freeCodeCamp-org/_usersSettings/tokens
### Installare agenti su target di deployment
Vai su [Azure Devops](https://dev.azure.com/freeCodeCamp-org) e registra l'agente dall'inizio nei requisiti [deployment groups](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_machinegroup).
> [!NOTE] Dovresti eseguire gli script nella home directory, e assicurati che nessun'altra directory `azagent` esista.
### Aggiornare gli agent
Attualmente aggiornare gli agent richiede che siano rimossi e riconfigurati. Questo è richiesto perché possano ottenere valori `PATH` e altre variabili d'ambiente di sistema. Dobbiame farlo per aggiornare Node.js sulle VM target di deployment.
1. Naviga e controlla lo status del servizio
```console
cd ~/azagent
sudo ./svc.sh status
```
2. Ferma il servizio
```console
sudo ./svc.sh stop
```
3. Disinstalla il servizio
```console
sudo ./svc.sh uninstall
```
4. Rimuovi l'agente dal pool della pipeline
```console
./config.sh remove
```
5. Rimuovi i file di config
```console
cd ~
rm -rf ~/azagent
```
Una volta completati gli step precedenti potrai ripetere gli stesi passi per installare l'agente.
# Manuale di volo - Email Blast
Usiamo uno [strumento CLI](https://github.com/freecodecamp/sendgrid-email-blast) per inviare la nostra newsletter settimanale. Per avviare e iniziare il processo:
1. Entra in DigitalOcean e avvia nuovi droplet sotto il progetto `Sendgrid`. Usa lo snapshot di Ubuntu Sendgrid con la data più recente. Questo viene pre-caricato con lo strumento CLI e lo script per ottenere le email dal database. Con il volume corrente, tre droplet sono sufficienti per mandare le email in un tempo decente.
2. Setta lo script per ottenere la lista delle email.
```console
cd /home/freecodecamp/scripts/emails
cp sample.env .env
```
Avrai bisogno di sostituire i valori segnaposto nel file `.env` con le tue credenziali.
3. Esegui lo script.
```console
node get-emails.js emails.csv
```
Questo salverà la lista delle email in un file `emails.csv`.
4. Separa le email in più file a seconda del numero di droplet di cui hai bisogno. Questo è più facile da fare usando `scp` per copiare la lista in locale e usare il tuo editor di testi preferito per separarle in file multipli. Ogni file avrà bisogno del header `email,unsubscribeId`.
5. Spostati alla directory CLI con `cd /home/sendgrid-email-blast` e configura lo strumento [seguendo la documentazione](https://github.com/freeCodeCamp/sendgrid-email-blast/blob/main/README.md).
6. Esegui lo strumento per mandare le email, seguendo la [documentazione d'uso](https://github.com/freeCodeCamp/sendgrid-email-blast/blob/main/docs/cli-steps.md).
7. Quando il email blast è completato, verifica che nessuna email abbia fallito prima di distruggere i droplet.

83
docs/i18n/italian/how-to-add-cypress-tests.md Normal file
View File

@ -0,0 +1,83 @@
# Come aggiungere test Cypress
Quando si fanno cambiamenti a JavaScript, CSS o HTML che possono cambiare le funzionalità o il layout di una pagina è importante aggiungere corrispondenti test di integrazione [Cypress](https://docs.cypress.io).
Per imparare come scrivere test Cypress, o specs, per favore vedi la [dcoumentazione](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html) ufficiale di Cypress.
> Nota: quando scrivi i test per freeCodeCamp, ricorda di aggiungere `/* global cy */` in cima al file per evitare problemi con ESLint.
## Dove aggiungere un test
- I test Cypress sono nella directory `./cypress`.
- I test Cypress per un modulo del curriculum sono nella corrispondente cartella del curriculum, per esempio `cypress/integration/learn/responsive-web-design/basic-css/index.js`.
## Come eseguire i test
> [!NOTE] Se stai usando GitPod, vedi [Cypress-GitPod Setup](/how-to-add-cypress-tests#cypress-gitpod-setup)
### 1. Assicurati che MongoDB e l'applicazione del client siano in esecuzione
- [Fai partire MongoDB e fai il seed del database](/how-to-setup-freecodecamp-locally#step-3-start-mongodb-and-seed-the-database)
- [Avvia l'applicazione del client di freeCodeCamp e il server API](/how-to-setup-freecodecamp-locally#step-4-start-the-freecodecamp-client-application-and-api-server)
### 2. Esegui i test cypress
Per eseguire i test su build di produzione, sostituisci `dev` con `prd` nella parte seguente.
- Per eseguire tutti i test nella cartella `./cypress`:
```console
npm run cypress:dev:run
```
- Per eseguire un singolo test:
```console
npm run cypress:dev:run -- --spec=cypress/pathToYourSpec/youSpecFileName.js
```
- Per creare una build di sviluppo, avvia il server di sviluppo e esegui tutti i test cypress end-to-end esistenti:
```console
npm run e2e:dev:run
```
## Setup di Cypress su GitPod
### 1. Assicurati di essere nella _Feature Preview_ di GitPod _dalla data del 02/01/2021_
- Vai a [GitPod Docs - Feature Preview](https://www.gitpod.io/docs/feature-preview/) per vedere come attivare la _Feature Preview_
### 2. Assicurati che l'ambiente di sviluppo sia in esecuzione
Se l'avvio di GitPod non sviluppa automaticamente l'ambiente:
- Avvia il database
```console
mongod
```
- Fai il seed del database
```console
npm run seed
```
- Sviluppa il server e il client
```console
npm run develop
```
### 3. Installa Cypress Build Tools
```console
npm run cypress:install-build-tools
```
- Quando chiesto dal terminale, seleziona il layout della tua tastiera per lingua/area
Ora, [puoi eseguire Cypress](/how-to-add-cypress-tests#_2-run-the-cypress-tests)

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

@ -0,0 +1,115 @@
> **Nota:** Questo è un **passaggio opzionale** ed è richiesto solo quando si lavora con flussi di lavoro sulle email
- [Introduzione](#introduction)
- [Installare MailHog](#installing-mailhog)
- [Usare Mailhog](#using-mailhog)
- [Link Utili](#useful-links)
## Introduzione
Alcuni flussi di lavoro di posta elettronica, come l'aggiornamento dell'email di un utente, richiedono l'api-server di back-end per inviare email in uscita. In alternativa all'utilizzo di un provider di servizi di posta elettronica per inviare messaggi di posta elettronica effettivi, Mailhog è uno strumento di sviluppo per il test di posta elettronica che catturerà i messaggi di posta elettronica inviati dalla tua istanza freeCodeCamp.
## Installare MailHog
MailHog può essere installato su macOS, Windows e Linux o usato con Docker
<details><summary>Installare MailHog con Docker</summary>
Se hai Docker installato puoi usare
```bash
docker run -d --name mailhog --rm mailhog/mailhog
```
per avviare MailHog in background e
```bash
docker stop mailhog
```
per arrestarlo.
Quando l'installazione è completa, puoi iniziare a [usare MailHog](#using-mailhog). </details>
<details><summary>Installare MailHog su macOS</summary>
Installa MailHog su macOS con [Homebrew](https://brew.sh/):
```bash
brew install mailhog
brew services start mailhog
```
I comandi qui sopra avvieranno un servizio mailhog in background.
Quando l'installazione sarà completa, potrai iniziare a [usare MailHog](#using-mailhog). </details>
<details><summary>Installare MailHog su Windows</summary>
Scarica l'ultima versione di MailHog dal [repository ufficiale di MailHog](https://github.com/mailhog/MailHog/releases). Trova e clicca sul link per la tua versione di Windows (32 o 64 bit) e un file .exe sarà scaricato sul tuo computer.
Quando il download è stato completato, clicca per aprire il file. Potrebbe comparire una notifica del firewall di Windows, chiedendo i permessi di accesso per MailHog. Dopo aver consentito l'accesso nel firewall, si aprirà un prompt standard della riga di comando di Windows con MailHog in esecuzione.
Chiudi MailHog chiudendo la finestra del prompt dei comandi. Per riaprire MailHog, clicka sul file eseguibile (.exe) di MailHog che è stato scaricato all'inizio; non è necessario scaricare un nuovo file di installazione.
Inizia a [usare MailHog](#using-mailhog). </details>
<details><summary>Installare MailHog su Linux</summary>
Come prima cosa, installa [Go](https://golang.org).
Usa i seguenti comandi per installare GO su sistemi basati su Debian come Ubuntu e Linux Mint.
```bash
sudo apt-get install golang
```
Usa i seguenti comandi per installare GO su sistemi basati su RPM come CentOS, Fedora, Red Hat Lnux, ecc.
```bash
sudo dnf install golang
```
In alternativa, esegui i seguenti comandi per installare GO.
```bash
sudo yum install golang
```
Ora imposta il path per Go con i seguenti comandi.
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
In fine, esegui i comandi seguenti per installare ed eseguire MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
Inizia a [usare MailHog](#using-mailhog). </details>
## Usare Mailhog
Apri una nuova scheda o finestra del browser e vai su [http://localhost:8025](http://localhost:8025) per aprire l'inbox di MailHog dopo che l'installazione è stata completata e MailHog è in esecuzione. L'inbox apparirà come nello screenshot qui sotto.
![MailHog Screenshot 1](https://contribute.freecodecamp.org/images/mailhog/1.jpg)
Le email spedite dalla tua installazione di freeCodeCamp appariranno come segue
![MailHog Screenshot 2](https://contribute.freecodecamp.org/images/mailhog/2.jpg)
Quando aprirai una mail saranno disponibili due tab che permettono di vedere le mail come solo testo o come contenuto sorgente. Assicurati che la tab solo testo sia selezionata come segue.
![MailHog Screenshot 3](https://contribute.freecodecamp.org/images/mailhog/3.jpg)
Tutti i link delle email dovrebbero essere clickabili e portare al loro URL.
## Link Utili
- Controlla il repository [MailHog](https://github.com/mailhog/MailHog) per ulteriori informazioni relative a MailHog. Ulteriori informazioni sono disponibili anche per quanto riguarda le configurazioni personalizzate di MailHog.

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

@ -0,0 +1,202 @@
# Come aiutare con le sfide video
Le sfide video sono un nuovo tipo di sfida nel programma di studi freeCodeCamp.
Una sfida video è una piccola sezione di un corso interamente su video su un argomento particolare. Una pagina di sfida video incorpora un video di YouTube. Ogni pagina di sfida ha una singola domanda a scelta multipla relativa al video. Un utente deve rispondere alla domanda correttamente prima di poter passare alla sfida video successiva nel corso.
Le pagine della sfida video sono create dai membri del team freeCodeCamp. Anche i video di YouTube sono caricati dai membri del team freeCodeCamp. Molte delle sfide video non hanno ancora domande ad esse associate.
Puoi aiutare creando domande a scelta multipla legate a sezioni del video e aggiungendo le domande ai file markdown per le sfide video.
## Template delle sfide
Di seguito è riportato un modello di come appaiono i file markdown delle sfide.
````md
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: Challenge Title
challengeType: 11
videoId: 'YouTube videoId for video challenge'
forumTopicId: 12345
---
# --description--
Challenge description text, in markdown
```html
<div>
example code
</div>
````
# --question--
Questi campi sono usati attualmente per le domande a scelta multipla nelle sfide di Python.
## --text--
Il testo della domanda va qui.
## --answers--
Risposta 1
---
Risposta 2
---
Altre risposte
## --video-solution--
Il numero della risposta corretta va qui.
````
## Creare domande per le sfide video
### Accedi al file markdown della sfida video
Puoi trovare i file markdown per le sfide video alle seguenti posizioni nel curriculum:
- [Analisi di dati con Python](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [Corso su TensorFlow 2.0](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Corso su Numpy](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [Corso su come funzionano le reti neurali](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Scegli un file markdown dalle opzioni sopra.
### Guarda velocemente il video associato alla sfida e crea una domanda a scelta multipla
Come prima cosa, trova l'id del video.
Ad esempio, nel seguente codice preso dall'intestazione di un file di markdown di una sfida video, il videoId è "nVAaxZ34khk". Su GitHub, le informazioni dovrebbero essere visibili in una tabella.
````
---
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis Example A challengeType: 11
videoId: nVAaxZ34khk
---
```
Come cosa successiva, accedi al video YouYube con quel `videoId`. L'URL del video sarà:
https://www.youtube.com/watch?v=[videoId] (sostituisci`videoId` nell'URL con l'ID del video, senza parentesi quadre)
Nell'esempio precedente, l'URL è https://www.youtube.com/watch?v=nVAaxZ34khk
Consulta velocemente il video YouTube con quel videoId e pensa a una domanda a scelta multipla basata sul contenuto del video.
### Aggiungere la domanda al file markdown
Puoi aggiungere la domanda localmente o usando l'interfaccia di GitHub. Per aggiungere la domanda localmente, è necessario [impostare freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md). Puoi anche trovare il file su GitHub e fare clic sul pulsante Modifica per aggiungere la domanda nel tuo browser.
Se una domanda non è ancora stata aggiunta a una sfida video, avrà la seguente domanda di default:
```md
# --question--
## --text--
Question text
## --answers--
Answer 1
---
Answer 2
---
More answers
## --video-solution--
1
```
Aggiungi/Cambia il testo della domanda sotto la parte che dice:
```
# --question--
## --text--
```
Add/Update answers (`Answer 1`, `Answer 2`, and so on) sotto `## --answers--`. Assicurati di aggiornare il numero sotto `## --video-solution--` con il numero della risposta corretta. Puoi aggiungere altre possibili domande seguendo lo stesso formato. Le domande e le risposte possono essere racchiuse tra virgolette.
### Esempi di domande
````md
# --question--
## --text--
Cosa visualizzerà questo codice JavaScript nella console?
```js
console.log('hello world');
````
## --answers--
hello *world*
---
**hello** world
---
hello world
---
## --video-solution--
3
````
````md
# --question--
## --text--
Cosa verrà visualizzato dopo l'esecuzione di questo codice:
```py
width = 15
height = 12.0
print(height/3)
````
## --answers--
39
---
4
---
4.0
---
5.0
---
5
## --video-solution--
3 ````
Per altri esempi, puoi guardare i file markdown dei seguenti corsi video. Tutte le sfide che hanno già domande: [Corso Python per tutti](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## Aprire una pull request
Dopo aver creato una o più domande, puoi fare un commit delle tue modifiche su un nuovo ramo e [aprire una pull request](how-to-open-a-pull-request.md).

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

@ -0,0 +1,183 @@
# Come aprire una Pull Request (PR)
Una pull request (PR) consente di inviare modifiche dal tuo fork su GitHub al repository principale di freeCodeCamp.org. Una volta che hai fatto delle modifiche al codice, puoi seguire queste linee guida per aprire una PR.
> [!NOTE] La tua PR dovrebbe essere in inglese. Vedi [qui](#index.md?id=translations) per come contribuire alla traduzione.
## Preparare un buon titolo PR
Si consiglia di utilizzare [Titolo convenzionale e messaggi](https://www.conventionalcommits.org/) per commit e le pull request. La convenzione ha il seguente formato:
> `<type>([optional scope(s)]): <description>`
>
> Per esempio:
>
> `fix(learn): tests for the do...while loop challenge`
Quando apri una Pull Request (PR), puoi usare la seguente lista per determinare il tipo (type), l'ambito (scope) (opzionale), e la descrizione.
**Tipo:**
| Tipo | Quando selezionare |
|:----- |:-------------------------------------------------------------------------------------- |
| fix | Cambiamenti o aggiornamenti/miglioramenti a funzioni, test, testo di una lezione, ecc. |
| feat | Solo se si aggiungono nuove funzionalità, test, ecc. |
| chore | Cambiamenti che non sono legati a codice, test, o testo di una lezione. |
| docs | Modifiche alla directory `/docs` o alle linee guida per i contributi, ecc. |
**Ambito:**
Puoi selezionare un ambito da [questo elenco di etichette](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
**Descrizione:**
Scrivila breve (meno di 30 caratteri) e semplice: puoi aggiungere ulteriori informazioni nella casella di descrizione PR e nei commenti.
Alcuni esempi di buoni titoli PR sarebbero:
- `fix(a11y): improved search bar contrast`
- `feat: add more tests to HTML and CSS challenges`
- `fix(api,client): prevent CORS errors on form submission`
- `docs(i18n): Chinese translation of local setup`
## Proporre una Pull Request
1. Una volta che le modifiche sono state effettuate, ti verrà chiesto di creare una pull request sulla pagina GitHub della tua fork.
![Immagine - Confrontare il prompt delle pull request su GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. Di default, tutte le pull request dovrebbero essere sul repository principale di freeCodeCamp, nel ramo `main`.
Assicurati che il tuo Base Fork sia impostato su freeCodeCamp/freeCodeCamp quando sollevi una Pull Request.
![Immagine - Confrontare i fork quando si effettua una pull request](https://contribute.freecodecamp.org/images/github/comparing-forks-for-pull-request.png)
3. Fai la pull request dal tuo ramo al ramo `main` di freeCodeCamp.
4. Nel corpo della tua PR includi un riepilogo più dettagliato delle modifiche apportate e perché.
- Ti sarà presentato un modello di pull request. Questa è una lista di controllo che avresti dovuto seguire prima di aprire la pull request.
- Compila i dettagli come ritieni opportuno. Queste informazioni saranno esaminate e i revisori decideranno se la tua pull request è accettata.
- Se la PR ha lo scopo di affrontare un'issue GitHub esistente, alla fine del corpo della descrizione della tua PR, usa la parola chiave _Closes_ con il numero dell'issue per [chiudere automaticamente questa issue se la PR è accettata](https://help.github.com/en/articles/closing-issues-using-keywords).
> Esempio: `Chiude #123` chiuderà l'issue 123
5. Indica se hai testato i tuoi cambiamenti su una copia locale del sito oppure no.
- Questo è molto importante quando si fanno cambiamenti che non sono solo modifiche a contenuto testuale come documentazione o descrizioni di sfide. Esempi di modifiche che hanno bisogno di essere testate localmente includono JavaScript, CSS o HTML che potrebbero cambiare funzionalità o layout di una pagina.
- Se la tua PR ha effetto sul comportamento di una pagina dovrebbe essere accompagnato da corrispondenti [test di integrazione di Cypress](/how-to-add-cypress-tests).
## Feedback sulle pull request
> Congratulazioni! :tada: per avere fatto una PR e grazie mille per aver speso del tempo per contribuire.
I nostri moderatori ora daranno un'occhiata e ti lasceranno un feedback. Ti preghiamo di essere paziente con i colleghi moderatori e di rispettare il loro tempo. Tutte le pull request sono riviste a tempo debito.
E come sempre, poni liberamente le tue domande nella [categoria 'Contributors' del nostro forum](https://forum.freecodecamp.org/c/contributors) o [nella chat room per i contributori](https://chat.freecodecamp.org/channel/contributors).
> [!TIP] Se vuoi contribuire a più di una PR, ti raccomandiamo di leggere la [guida su fare modifiche e sincronizzare](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) per evitare di dover cancellare il tuo fork.
## Conflitti su una pull request
I conflitti possono sorgere perché molti contributori lavorano sul repository e le modifiche possono interrompere la tua PR in attesa di una revisione e di un merge.
Spesso non si può richiedere un rebase, perché schiacciamo tutti i commit, tuttavia se è richiesto un rebase qui è quello che dovresti fare.
### Per le solite correzioni di bug e funzionalità
Quando stai lavorando su normali bug e funzionalità sul nostro ramo di sviluppo `main`, puoi fare un semplice rebase:
1. Ricostruisci la tua copia locale:
```console
git checkout <pr-branch>
git pull --rebase upstream main
```
2. Risolvi eventuali conflitti e aggiungi / modifica i commit
```console
# O
git add .
git commit -m "chore: resolve conflicts"
# Or
git add .
git commit --amend --no-edit
```
3. Ritorna le modifiche alla PR
```console
git push --force origin <pr-branch>
```
### Per il curriculum e le caratteristiche future
Quando stai lavorando su funzionalità dei rami `next-*` del nuovo curriculum, devi fare un cherry pick:
1. Assicurati che il tuo upstream sia sincronizzato con il tuo repository locale:
```console
git checkout main
git fetch --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects
```
2. Fai un backup
a. Elimina anche il ramo locale dopo aver effettuato un backup (se lo hai ancora localmente):
```console
git checkout <pr-branch-name>
# example:
# git checkout feat/add-numpy-video-question
git checkout -b <backup-branch-name>
# example:
# git checkout -b backup-feat/add-numpy-video-question
git branch -D <pr-branch-name>
```
b. O solo un backup del ramo pr (se non lo hai localmente):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
# esempio:
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
4. Inizia con una slate pulita:
```console
git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>
```
5. Risolvere eventuali conflitti e pulire, installare test di esecuzione
```console
npm run clean
npm ci
npm run test:curriculum --superblock=<superblock-name>
# example:
# npm run test:curriculum --superblock=python-for-everybody
```
6. Se tutto sembra funzionare fai un push alla PR
```console
git push --force origin <pr-branch-name>
```

54
docs/i18n/italian/how-to-proofread-files.md Normal file
View File

@ -0,0 +1,54 @@
# Come revisionare le traduzioni
Il nostro team di revisione è responsabile di controllare che le traduzioni riflettano accuratamente il testo originale. Ci affidiamo ai revisori per avere delle traduzioni di alta qualità.
Tutte le nostre traduzioni sono fatte a mano, da veri esseri umani. La revisione assicura che ci sia un tono consistente su tutte le nostre risorse tradotte, come ad esempio il curriculum.
Per iniziare a revisione visita [la nostra piattaforma di traduzione](https://translate.freecodecamp.org) e fai il login. Seleziona °Go to console° nella barra di navigazione in alto per cambiare dalla public view alla workspace view.
## Seleziona un file
Dovresti vedere la lista di progetti a cui ti è stato dato accesso. Seleziona il progetto che vorresti revisionare, poi seleziona la lingua.
![Immagine - Lista dei dei file per la il revisore](https://contribute.freecodecamp.org/images/crowdin/proof-file-tree.png)
Ora dovresti vedere la lista dei file disponibili. Scegli il file selezionando il pulsante `Proofread` a destra del file, e scegliendo quindi `Proofreading` dal menu che compare.
> [!NOTE] Se sei in workspace view, ma vuoi larorare sulla [traduzione di un file](./how-to-translate-files.md) invece di revisionare, puoi selezionare `Crowdsourcing` dal menu.
## Revisionare le traduzioni
![Immagine - VIsta Proofreading](https://contribute.freecodecamp.org/images/crowdin/proofread.png)
<!--Add proofread/crowdsource button to the image-->
Qui vedrai la lista delle stringhe nel file selezionato con le relative traduzioni. La traduzione che è mostrata qui è la traduzione che ha ricevuto il maggior punteggio (tra voti positivi e negativi) dalla comunità di traduttori.
Anche se puoi vedere _tutte_ le traduzioni proposte per una certa stringa, il punteggio della comunità (determinato da voti positivi e voti negativi) dovrebbe essere preso in considerazione quando scegli quale traduzione approvare. La comunità può rivedere le traduzioni proposte e raccomandare quale è la più chiara e accurata.
1. Questa è la stringa originale (in inglese).
2. Questa è la corrispondente stringa tradotta. La proposta di traduzione più popolare, basata su voti positivi e negativi, sarà mostrata qui.
3. Cliccando il pulsante di spunta approverai la traduzione.
4. Crowdin mostrerà lo stato di ogni stringa. `Done` significa che una traduzione è stata approvata e sarà scaricata nel prossimo aggiornamento delle traduzioni. `Todo` significa che la stringa non è stata revisionata. `Hidden`significa che la stringa e bloccata e _non deve essere tradotta_. `Comment` significa che la stringa ha un relativo commento.
5. Le traduzioni possono essere selezionate con i checkbox e approvate in un'azione cumulativa.
6. Qui puoi vedere le traduzioni proposte dalla comunità, i punteggi di popolarità, e le traduzioni suggerite da Crowdin.
7. Questo pulsante mostra/nasconde la scheda a destra, dove puoi vedere traduzioni, commenti, traduzioni in memoria, e termini del glossario.
8. Crowdin mostra qui i messaggi di errore dai controlli di qualità. In altre parole, se qualcosa non sembra corretto nella traduzione, Crowdin te lo dirà. Queste traduzioni devono essere approvate con attenzione.
Non sono necessarie altre azioni una volta che un file è stato revisionato.
> [!NOTE] Approvare una stringa in modalità di revisione la segnerà come completata e farà sì che sia scaricata nel prossimo pull da Crowdin a GitHub.
## Diventare un proofreader/revisore
Se hai domande o sei interessato a diventare proofreader, puoi contattarci nella [chat room per i contributori](https://chat.freecodecamp.org/channel/contributors). In genere diamo i permessi di revisore se è da un po' che contribuisci a freeCodeCamp.
Il nostro staff e i moderatori della community sono sempre alla ricerca di volontari come te che ci aiutino a rendere disponibili al mondo traduzioni di alta qualità.
> [!NOTE] Crowdin ti permette di approvare le tue traduzioni. In genere, è meglio permettere ad un altro proofreader di rivedere le tue proposte di traduzione per maggior sicurezza che non ci siano errori.
## Creare un canale su Chat per una lingua
Per la maggior parte, incoraggiamo l'uso della [chat room per i contributori](https://chat.freecodecamp.org/channel/contributors) per tutte le comunicazioni. Ma se il team di volontari per una certa lingua cresce, possiamo considerare di creare un canale aggiuntivo per la lingua.
Se sei un proofreader e sei interessato ad avere un canale dedicato sul server di chat per una specifica lingua, [compila questo modulo](https://forms.gle/XU5CyutrYCgDYaVZA).

551
docs/i18n/italian/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,551 @@
Segui queste linee guida per impostare freeCodeCamp localmente nel tuo sistema. Te lo raccomandiamo caldamente se desideri contribuire regolarmente.
Alcuni di questi flussi di lavoro contributivi – come la correzione di bug nel codebase o nel curriculum – hanno bisogno di eseguire freeCodeCamp localmente sul computer.
> [!TIP] Se non sei interessato a configurare freeCodeCamp localmente, considera di utilizzare Gitpod, un ambiente di sviluppo online gratuito.
>
> [![Apri in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (Avvia un ambiente di sviluppo ready-to-code per freeCodeCamp nel tuo browser.)
### Come preparare la macchina locale
Inizia installando i prerequisiti software per il tuo sistema operativo.
Sosteniamo principalmente lo sviluppo su sistemi Linux e basati su Unix. Il nostro staff e i collaboratori della community lavorano regolarmente con il codebase utilizzando strumenti installati su Ubuntu e macOS.
Supportiamo anche Windows 10 via WSL2, che puoi preparare [leggendo questa guida](/how-to-setup-wsl).
Alcuni membri della comunità sviluppano anche su Windows 10 nativamente con Git per Windows (Git Bash) e altri strumenti installati su Windows. Al momento non disponiamo di un supporto ufficiale per una tale configurazione, consigliamo invece di utilizzare WSL2.
**Prerequisiti:**
| Prerequisito | Versione | Note |
| --------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------ |
| [Node.js](http://nodejs.org) | `14.x` | [LTS Schedule](https://github.com/nodejs/Release#release-schedule) |
| npm (viene fornito in bundle con node) | `6.x` | Non ha LTS rilasci, utilizziamo la versione in bundle con Node LTS |
| [Server Community MongoDB](https://docs.mongodb.com/manual/administration/install-community/) | `4.0.x` | [Note di rilascio](https://docs.mongodb.com/v4.0/release-notes/) |
> [!ATTENTION] Se hai una versione diversa, per favore installa la versione raccomandata. Possiamo supportare solo i problemi di installazione per le versioni consigliate. Vedi [risoluzione dei problemi](#troubleshooting) per i dettagli.
Se Node.js è già installato sulla macchina, eseguire i seguenti comandi per convalidare le versioni:
```console
node -v
npm -v
```
> [!TIP] Consigliamo vivamente di aggiornare le ultime versioni stabili del software sopra elencato, note anche come versioni con supporto a lungo termine (LTS).
Una volta che avrai installato i prerequisiti, dovrai preparare il tuo ambiente di sviluppo. Questo è comune a molti flussi di lavoro di sviluppo, e si dovrà fare solo una volta.
**Segui questi passaggi per preparare il tuo ambiente di sviluppo:**
1. Installa [Git](https://git-scm.com/) o il tuo client Git preferito, se non lo hai già. Aggiornamento alla versione più recente; la versione fornita con il tuo sistema operativo potrebbe essere obsoleta.
2. (Facoltativo ma consigliato) [Imposta una chiave SSH](https://help.github.com/articles/generating-an-ssh-key/) per GitHub.
3. Installa un editor di codice a tua scelta.
Consigliamo vivamente di utilizzare [Visual Studio Code](https://code.visualstudio.com/) o [Atom](https://atom.io/). Questi sono editor di codice ottimi, grauiti e open source.
4. Imposta il linting per il tuo editor di codice.
Dovresti avere [ESLint in esecuzione nel tuo editor](http://eslint.org/docs/user-guide/integrations.html), ed esso metterà in evidenza tutto ciò che non è conforme alla [Guida di stile JavaScript di freeCodeCamp](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
> [!TIP] Per favore non ignorare alcun errore di linting. Essi sono destinati ad **aiutarti** e a garantire un codice pulito e semplice.
## Esegui il fork del repository su GitHub
Il [Forking](https://help.github.com/articles/about-forks/) è un passaggio nel quale fai una tua copia del repository principale di freeCodeCamp (noto anche come _repo_) su GitHub.
Questo è essenziale, in quanto consente di lavorare sulla propria copia di freeCodeCamp su GitHub, o di scaricare (clonare) il tuo repository per lavorare localmente. Più tardi, potrai richiedere che le tue modifiche siano integrate (pull) nel repository principale dal tuo fork tramite una pull request (PR).
> [!TIP] Il repository principale su `https://github.com/freeCodeCamp/freeCodeCamp` è spesso indicato come il repository `upstream`.
>
> Il tuo fork situato si `https://github.com/YOUR_USER_NAME/freeCodeCamp` è spesso chiamato il repository `origin`. `YOUR_USER_NAME` è sostituito dal tuo nome utente GitHub.
**Segui questi passaggi per effettuare il fork del repository `https://github.com/freeCodeCamp/freeCodeCamp`:**
1. Vai al repository freeCodeCamp su GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
2. Fai clic sul pulsante "Fork" nell'angolo in alto a destra dell'interfaccia ([Maggiori dettagli qui](https://help.github.com/articles/fork-a-repo/))
3. Dopo che è stato creato un fork del repository, sarai portato alla tua copia del repository di freeCodeCamp su `https://github.com/YOUR_USER_NAME/freeCodeCamp` (`YOUR_USER_NAME` è sostituito dal tuo nome utente GitHub.)
<details>
<summary>
Come effettuare il fork di freeCodeCamp su GitHub (screenshot)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="Come fare il fork di freeCodeCamp su GitHub" />
</details>
## Clona il tuo fork da GitHub
La [Clonazione](https://help.github.com/articles/cloning-a-repository/) consiste nello **scaricare** una copia di un repository da una `posizione remota` che è di proprietà tua o di qualcun altro. Nel tuo caso, questa posizione remota è il tuo `fork` del repository di freeCodeCamp che dovrebbe essere disponibile su `https://github.com/YOUR_USER_NAME/freeCodeCamp`. (`YOUR_USER_NAME` è sostituito dal tuo nome utente GitHub.)
> [!WARNING] Se stai lavorando su una Distro di Linux su WSL2, potresti avere problemi di performace e stabilità eseguendo il progetto in una cartella che è condivisa tra Windows e WSL2 (per esempio `/mnt/c/Users/`). Quindi ti raccomandiamo di clonare il repo in una cartella che è usata principalmente dal Distro di Linux su WSL2 e non condivisa direttamente con Windows (per esempio `~/PROJECTS/`).
>
> Vedi [questa issue su GitHub](https://github.com/freeCodeCamp/freeCodeCamp/issues/40632) per ulterioni informazioni su questo problema.
Esegui questi comandi sulla tua macchina locale:
1. Apri un terminale / prompt dei comandi / Shell nella directory dei progetti
_cioè: `/yourprojectsdirectory/`_
2. Clona il tuo fork di freeCodeCamp, sostituendo `YOUR_USER_NAME` con il tuo nome utente GitHub
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
Questo scaricherà l'intero repository freeCodeCamp nella directory dei tuoi progetti.
Nota: `--depth=1` crea un clone superficiale del fork, con la sola cronologia dei commit più recente.
## Imposta la sincronizzazione dal genitore
Ora che hai scaricato una copia del fork, dovrai configurare un remote `upstream` che punti al repository padre.
[Come accennato poc'anzi](#fork-the-repository-on-github), il repository principale fa riferimento al repository `upstream`. Il tuo fork fa riferimento al repository `origin`.
Hai bisogno di un riferimento dal tuo clone locale al repository `upstream` oltre che al repository `origin`. In questo modo potrai sincronizzare le modifiche dal repository principale senza bisogno di fare ripetuti fork e clonazioni.
1. Cambia la directory nella nuova directory freeCodeCamp:
```console
cd freeCodeCamp
```
2. Aggiungi un riferimento remoto al repository freeCodeCamp principale:
```console
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Assicurati che la configurazione sia corretta:
```console
git remote -v
```
L'output dovrebbe apparire simile al seguente (sostituendo `YOUR_USER_NAME` con il tuo username di GitHub):
```console
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Eseguire freeCodeCamp localmente
Ora che disponi di una copia locale di freeCodeCamp, potrai seguire queste istruzioni per eseguirlo localmente. Questo ti permetterà di:
- Vedere un'anteprima delle modifiche come apparirebbero sulla piattaforma di apprendimento.
- Lavorare su problemi e miglioramenti relativi all'interfaccia utente.
- Fare il debug e la correzione dei problemi con i server delle applicazioni e le app client.
Se incontri un problema, fai prima una ricerca del problema sul web per vedere se ha già una risposta. Se non riesce a trovare una soluzione, ti preghiamo di fare una ricerca nelle nostra pagina delle [Issues su GitHub](https://github.com/freeCodeCamp/freeCodeCamp/issues) per trovare una soluzione o segnalare il problema se non è ancora stato fatto.
E come sempre, fai liberamente le tue domande nella [categoria 'Contributors' sul forum](https://forum.freecodecamp.org/c/contributors) o [sul server di chat](https://chat.freecodecamp.org/home).
> [!TIP] Puoi saltare l'esecuzione di freeCodeCamp localmente se stai semplicemente modificando i file. Per esempio, facendo un `rebase`, o risolvendo dei conflitti di `merge`.
>
> Puoi sempre tornare in seguito a questa parte della guida. Dovresti saltare questi step **solo se** non hai bisogno di eseguire le app sul tuo computer.
>
> [Salta alle istruzioni per fare modifiche](#making-changes-locally).
### Configurare le dipendenze
#### Passo 1: Impostare il file delle variabili d'ambiente
Le chiavi API predefinite e le variabili d'ambiente sono memorizzate nel file `sample.env`. Questo file deve essere copiato in un nuovo file chiamato `.env` a cui si accede dinamicamente durante la fase di installazione.
```console
# Creare una copia del "sample.env" e denominarlo ".env".
# Popolarlo con le necessarie chiavi API e secrets:
# macOS / Linux
cp esempio. nv .env
# Windows
copy sample.env .env
```
_Non_ è necessario cambiare le chiavi nel file `.env` per eseguire l'applicazione localmente. Puoi lasciare i valori predefiniti copiati da `sample.env` così come sono.
> [!TIP] Tieni a mente che se vuoi usare servizi come Auth0 o Algolia, dovrai ottenere delle API key per quei servizi per conto tuo e modificare il file `.env` di conseguenza.
#### Passo 2: Installa le dipendenze
Questo passaggio installerà le dipendenze richieste per l'esecuzione dell'applicazione:
```console
npm ci
```
#### Passo 3: Avvia MongoDB e fai il seed del database
Prima di poter eseguire l'applicazione localmente, è necessario avviare il servizio MongoDB.
> [!NOTE] A meno che tu non abbia MongoDB in esecuzione in un setup differente dal default, l'URL salvato come `MONGOHQ_URL` nel file `.env` dovrebbe andare bene. Se usi una configurazione personalizzata, modifica il valore come necessario.
Avvia il server MongoDB in un terminale separato:
- Su macOS & Ubuntu:
```console
mongod
```
- Su Windows, è necessario specificare il percorso completo dell'eseguibile `mongod`
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
Assicurati di sostituire `3.6` con la versione che hai installato
> [!TIP] Puoi evitare di dover avviare MongoDB ogni volta se lo installi come servizio in background. Puoi [saperne di più nella loro documentazione per il tuo sistema operativo](https://docs.mongodb.com/manual/administration/install-community/)
Successivamente, facciamo il seed del database. In questo passaggio, eseguiamo il comando sottostante che popola il server MongoDB con alcuni set di dati iniziali richiesti dai servizi. Tra questi figurano alcuni schemi, tra le altre cose.
```console
npm run seed
```
#### Passo 4: Avviare l'applicazione client freeCodeCamp e il server API
Ora è possibile avviare il server API e le applicazioni client.
```console
npm run develop
```
Questo singolo comando attiverà tutti i servizi, compreso il server API e le applicazioni client disponibili su cui lavorare.
> [!NOTE] Una volta pronto, apri un browser web e **visita <http://localhost:8000>**. Se l'app si carica, congratulazioni, sei a posto! Hai ora una copia dell'intera piattaforma di apprendimento di freeCodeCamp in esecuzione sul tuo computer.
> [!TIP] Il server API serve le API su `http://localhost:3000`. L'app Gatsby serve il client dell'applicazione su `http://localhost:8000`
> Se visiti <http://localhost:3000/explorer> dovresti vedere le API disponibili.
## Accedi con un utente locale
La tua configurazione locale crea automaticamente un utente locale nel database. Facendo clic sul pulsante `Accedi` ti autenticherai automaticamente nell'applicazione locale.
Tuttavia, accedere alla pagina del portfolio utente è un po' difficile. In fase di sviluppo, Gatsby si occupa di servire le pagine lato client e quindi otterrai una pagina `404` per il portfolio utente quando lavorerai localmente.
Basta cliccare sul pulsante **"Preview Custom 404 Page"** per passare alla pagina corretta.
<details>
<summary>
Come accedere quando si lavora localmente (screenshot)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="Come accedere quando si lavora localmente" />
</details>
## Apportare modifiche a livello locale
Ora puoi apportare modifiche ai file e inviare le modifiche al clone locale del tuo fork.
Segui questi passaggi:
1. Controlla di essere sul ramo `main`:
```console
git status
```
Dovresti ottenere un output come questo:
```console
On branch main
Your branch is up-to-date with 'origin/main'.
niente da commit, directory di lavoro pulita
```
Se non sei sul ramo main o la directory su cui stai lavorando non è pulita, risolvi file e commit in sospeso e fai il checkout di `main`:
```console
git checkout main
```
2. Sincronizza il tuo ramo main locale con gli ultimi aggiornamenti dal ramo `main` dell'upstream di freeCodeCamp:
> [!WARNING] Se hai delle pull request in sospeso fatte dal ramo `main` del tuo fork, le perderai alla fine di questi passaggi.
>
> Dovresti assicurarti che la tua pull request sia unita da un moderatore prima di eseguire questo passaggio. Per evitare questo scenario, dovresti **sempre** lavorare su un ramo che non sia `main`.
Questo passaggio **sincronizzerà le ultime modifiche** dal repository principale di freeCodeCamp. È importante che tu faccia un rebase del tuo ramo utilizzando l'ultima versione di `upstream/main` quanto più spesso possibile per evitare conflitti successivamente.
Aggiorna la tua copia locale del repository upstream freeCodeCamp:
```console
git fetch upstream
```
Fai un hard reset del tuo ramo main con il ramo main di freeCodeCamp:
```console
git reset --hard upstream/main
```
Fai un push del ramo main al tuo origin per avere una cronologia pulita nel tuo fork su GitHub:
```console
git push origin main --force
```
Puoi controllare che il tuo main attuale corrisponda con upstream/main facendo un diff:
```console
git diff upstream/main
```
L'output risultante dovrebbe essere vuoto.
3. Crea un nuovo ramo:
Lavorare su un ramo separato per ogni problema ti aiuta a mantenere pulita la tua copia di lavoro locale. Non dovresti mai lavorare su `main`. Questo sporcherebbe la tua copia di freeCodeCamp e potrebbe essere necessario ricominciare da capo con un nuovo clone o fork.
Controlla di essere su `main` come spiegato in precedenza, e crea un ramo da lì:
```console
git checkout -b fix/update-guide-for-xyz
```
Il nome del ramo dovrebbe iniziare con un `fix/`, `feat/`, `docs/`, ecc. Evita di utilizzare i numeri delle issue nei rami. Tienili brevi, significativi e unici.
Alcuni esempi di buoni nomi dei rami sono:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Modifica le pagine e lavora sul codice nel tuo editor di testo preferito.
5. Una volta che sei soddisfatto delle modifiche, dovresti opzionalmente eseguire freeCodeCamp localmente per visualizzarle in anteprima.
6. Assicurati di correggere eventuali errori e controlla la formattazione delle modifiche.
7. Controlla e conferma i file che stai aggiornando:
```console
git status
```
Questo dovrebbe mostrare un elenco di file `unstaged` che hai modificato.
```console
Su branch feat/documentation
Il ramo è aggiornato con 'upstream/feat/documentation'.
Changes were not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in the working directory)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
modified: docs/how-to-work-on-guide-articles.md
...
```
8. Fai lo stage delle modifiche e crea un commit:
In questo passaggio, dovresti contrassegnare solo i file che hai modificato o aggiunto tu stesso. Se necessario è possibile eseguire un reset e risolvere i file che non hai intenzione di modificare.
```console
git add path/to/my/changed/file.ext
```
Oppure puoi aggiungere tutti i file `unstaged` all'area di staging:
```console
git add .
```
Solo i file che sono stati spostati nell'area di staging verranno aggiunti quando si effettua un commit.
```console
git status
```
Output:
```console
On branch feat/documentation
Your branch is up to date with 'upstream/feat/documentation'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
modified: docs/how-to-work-on-guide-articles.md
```
Ora, è possibile eseguire il commit delle modifiche con un breve messaggio come questo:
```console
git commit -m "fix: my short commit message"
```
Alcuni esempi:
```md
fix: update guide article for Java - for loop
feat: add guide article for alexa skills
```
Facoltativo:
Raccomandiamo caldamente di creare un messaggio di commit convenzionale. Questa è una buona pratica che vedrai su alcuni dei più popolari repository Open Source. Come sviluppatore, questo ti incoraggia a seguire le pratiche standard.
Alcuni esempi di messaggi di commit convenzionali sono:
```md
fix: update HTML guide article
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
docs: update contributing guidelines
```
Mantieni questi messaggi brevi, non più di 50 caratteri. È sempre possibile aggiungere ulteriori informazioni nella descrizione del messaggio di commit.
Questo non richiede tempo aggiuntivo rispetto a un messaggio non convenzionale come 'fupdate file' o 'add index.md'
Puoi saperne di più sul perché dovresti usare i commit convenzionali [qui](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
9. Se ti accorgi di dover modificare un file o aggiornare il messaggio del commit dopo aver fatto un commit puoi farlo dopo aver modificato i file con:
```console
git commit --amend
```
Questo aprirà un editor di testo predefinito come `nano` o `vi` dove potrai modificare il titolo del messaggio di commit e aggiungere/modificare la descrizione.
10. Successivamente, è possibile inviare le modifiche al fork:
```console
git push origin branch/name-here
```
## Proporre una Pull Request (PR)
Dopo aver effettuato le modifiche, controlla qui per [come aprire una Pull Request](how-to-open-a-pull-request.md).
## Comandi rapidi
Un rapido riferimento ai comandi di cui avrai bisogno quando lavorerai localmente.
| comando | descrizione |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `npm ci` | Installa / reinstalla tutte le dipendenze e avvia i diversi servizi. |
| `npm run seed` | Analizza tutti i file di markdown della sfida e li inserisce in MongoDB. |
| `npm run develop` | Avvia il server API freeCodeCamp e le applicazioni client. |
| `npm run storybook` | Esegui Storybook per sviluppo dei componenti di library. |
| `npm test` | Esegui tutti i test JS del sistema inclusi client, server, link e test delle sfide. |
| `npm run test:client` | Esegui la test suite del client. |
| `npm run test:curriculum` | Esegui la test suite del curriculum. |
| `npm run test:curriculum --block='Basic HTML and HTML5'` | Esegui i test di uno specifico blocco. |
| `npm run test:curriculum --superblock='responsive-web-design'` | Esegui i test di uno specifico superblocco. |
| `npm run test-curriculum-full-output` | Esegui la suite di test del curriculum, senza arrestarsi dopo il primo errore |
| `npm run test:server` | Esegui la suite di test del server. |
| `npm run e2e` | Esegui i test di Cypress end to end. |
| `npm run clean` | Disistalla tutte le dipendenze e pulisce la cache. |
## Risoluzione Dei Problemi
### Problemi con l'installazione dei prerequisiti raccomandati
Sviluppiamo regolarmente sui sistemi operativi più nuovi o più popolari come macOS 10.15 o successivi, Ubuntu 18.04, e Windows 10 con WSL2.
Ti raccomandiamo di fare ricerche sui tuoi problemi specifici usando risorse come Google, Stack Overflow, e Stack Exchange. C'è una buona probabilità che qualcuno abbia incontrato lo stesso problema e ci sia già una risposta alla tua domanda specifica.
Se sei su un sistema operativo diverso e/o continui ad avere dei problemi, visita [ottenere aiuto](#getting-help).
> [!WARNING]
>
> Per favore evita di creare issue su GitHub per problemi con i prerequisiti. Sono al di fuori dell'ambito di questo progetto.
### Problemi con UI, Font, errori di build, ecc.
Se si verificano problemi con l'interfaccia utente, i caratteri o vedi errori di compilazione, una pulizia potrebbe essere utile:
```console
npm run clean
npm ci
npm run seed
npm run develop
```
O
Usa il collegamento
```
npm run clean-and-develop
```
Se continui ad incontrare problemi con la compilazione, ti consigliamo di ripulire lo spazio di lavoro.
Usa `git clean` in modalità interattiva:
```
git clean -ifdX
```
<details>
<summary>
Come pulire i file git non tracciati (screenshot)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="Come pulire i file git non tracciati" />
</details>
### Problemi con API, logic, invio delle sfide, ecc.
Se non riesci ad accedere e invece vedi un banner con un messaggio di errore che verrà segnalato a freeCodeCamp, ti preghiamo di controllare che la porta locale `3000` non sia in uso da un programma diverso.
**Su Linux / macOS / WSL su Windows - Dal terminale:**
```console
netstat -a | grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
**Su Windows - d PowerShell con privilegi elevati:**
```powershell
netstat -ab | Select-String "3000"
TCP 0.0.0.0:3000 DESKTOP LISTENING
```
### Problemi nell'installazione delle dipendenze
Se incontri degli errori durante l'installazione delle dipendenze, assicurati di non essere in una rete ristretta o che le impostazioni del tuo firewall non ti impediscono di accedere alle risorse.
La prima configurazione può richiedere un po' di tempo a seconda della larghezza di banda della rete. Sii paziente, e se continui a rimanere bloccato ti raccomandiamo di usare GitPod invece di un setup offline.
## Ottenere Aiuto
Se sei bloccato e hai bisogno di aiuto, 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).
Potrebbe esserci un errore nella console del browser o in Bash / Terminal / Linea di comando che ti aiuterà a identificare il problema. Fornisci questo messaggio di errore nella descrizione del problema in modo che gli altri possano identificare più facilmente il problema e aiutarti a risolverlo.

133
docs/i18n/italian/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,133 @@
# Impostare freeCodeCamp sul sottosistema Windows per Linux (WSL)
> [!NOTE] Prima di seguire queste istruzioni assicurati che il sistema soddisfi i requisiti
>
> **WSL 2**: Windows 10 a 64 bit (Versione 2004, Build 19041 o superiore) - disponibile per tutte le distribuzioni tra cui Windows 10 Home.
>
> **Docker Desktop per Windows**: Vedi i rispettivi requisiti per [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) e [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements)
Questa guida copre alcuni passi comuni con la configurazione di WSL2. Una volta che i problemi più comuni con WSL2 sono stati considerati, dovresti essere in grado di seguire [questa guida per settare freeCodeCamp in locale](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) per lavorare su Windows usando una distribuzione WSL come Ubuntu.
## Abilita WSL
Segui le istruzioni sulla [documentazione ufficiale](https://docs.microsoft.com/en-us/windows/wsl/install-win10) per installare WSL1 seguito dall'aggiornamento a WSL2.
## Installare Ubuntu
1. Si consiglia l'uso di Ubuntu-18.04 o superiore con WSL2.
> [!NOTE]
>
> Anche se si possono utilizzare altre distribuzioni non basate su debian, hanno tutte i loro trabocchetti e sono al di là della portata di questa guida.
2. Aggiorna le dipendenze per il sistema operativo
```console
sudo apt update
sudo apt upgrade -y
# cleanup
sudo apt autoremove -y
```
## Imposta Git
Git è preinstallato in Ubuntu 18.04, verifica la versione di git con `git --version`.
```output
~
❯ git --version
git version 2.25.1
```
(Facoltativo ma consigliato) Ora puoi procedere alla [impostazione delle tue chiavi ssh](https://help.github.com/articles/generating-an-ssh-key) con GitHub.
## Installazione di un editor di codice
Consigliamo vivamente di installare [Visual Studio Code](https://code.visualstudio.com) su Windows 10. Ha un grande supporto per WSL e installa automaticamente tutte le estensioni necessarie sulla tua distribuzione WSL.
Essenzialmente, modificherai e memorizzerai il tuo codice su Ubuntu-18.04 con Visual Studio Code installato su Windows.
Se usi [IntelliJ Idea](https://www.jetbrains.com/idea/), potresti aver bisogno di aggiornare il tuo interprete Node e il gestore di pacchetti Npm a quello installato nella tua distribuzione WSL.
Puoi controllare queste impostazioni andando su Settings > Languages & Frameworks > Node.js and NPM.
## Installazione di Docker Desktop
**Docker Desktop per Windows** ti permette di installare e eseguire database come MongoDB e altri servizi come NGINX. Questo è utile per evitare problemi comuni con l'installazione di MongoDB o altri servizi direttamente su Windows o WSL2.
Segui le istruzioni nella [documentazione ufficiale](https://docs.docker.com/docker-for-windows/install) e installa Docker Desktop per la tua distribuzione Windows.
Ci sono dei requisiti hardware minimi per un'esperienza migliore.
## Configura Docker Desktop per WSL
Una volta che Docker Desktop sarà installato, [segui queste istruzioni](https://docs.docker.com/docker-for-windows/wsl) e configuralo per usare l'installazione di Ubuntu 18.04 come Backend.
Questo fa si che i container siano eseguiti su WSL invece che su Windows. Sarai in grado di accere ai servizi da `http://localhost` sia su Windows che su Ubuntu.
## Installa MongoDB da Docker Hub
Una volta che hai configurato Docker Desktop per lavorare con WSL2, segui questi step per avviare un servizio MongoDB:
1. Avvia un nuovo terminale Ubuntu-18.04
2. Scarica `MongoDB 4.0.x` da dockerhub
```console
docker pull mongo:4.0
```
3. Avvia il servizio MongoDB sulla porta `27017` e configuralo perché sia eseguito automaticamente al riavvio del sistema
```console
docker run -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb \
--restart unless-stopped \
-d mongo:4.0
```
4. Ora puoi accedere al servizio sia da Windows che da Ubuntu da `mongodb://localhost:27017`.
## Installazione di Node.js e npm
Raccomandiamo di installare la release LTS di Node.js con un gestore di versioni di node (node version manager): [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
Una volta installato usa questi comandi per installare e usare la versione di Node.js che ti serve
```console
nvm install --lts
# O
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm use 12
```
Node.js è impacchetato con `npm`, puoi aggiornare all'ultima versione di `npm` con:
```console
npm install -g npm@latest
```
## Imposta freeCodeCamp localmente
Ora che hai installato i pre-requisiti, segui [la nostra guida per settare freeCodeCamp localmente](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) per clonare, installare e settare freeCodeCamp sul tuo computer.
> [!WARNING]
>
> Si prega di notare che, in questo momento, la configurazione per i test Cypress (e le relative esigenze GUI) sono un lavoro in corso. Dovresti essere comunque in grado di lavorare sulla maggior parte del codebase.
## Link Utili
- [Un setup di WSL2 per lo sviluppo con Ubuntu 20.04, Node.js, MongoDB, VS Code e Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - un articolo di Mrugesh Mohapatra (Staff Developer at freeCodeCamp.org)
- Domande frequenti su:
- [Sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [Docker Desktop per Windows](https://docs.docker.com/docker-for-windows/faqs)

131
docs/i18n/italian/how-to-test-translations-locally.md Normal file
View File

@ -0,0 +1,131 @@
# Come testare le traduzioni in locale
> [!NOTE] Questo processo non è richiesto, ma documentato nel caso tu voglia vedere la preview delle tue traduzioni.
Se vuoi testare le tue traduzioni in una istanza locale della piattaforma `/learn` di freeCodeCamp, assicurati prima di aver [preparato il codebase](how-to-setup-freecodecamp-locally.md).
## Attivare una lingua
Ci sono alcuni step da fare per avere una build del codebase nella lingua di tua scelta.
Prima, visita il file `config/i18n/all-langs.js` per aggiungere la lingua alle lingue disponibili nella lista e configurare i valori. Ci sono quattro oggetti qui.
- `availableLangs`: Aggiungi il nome testuale della lingua agli array `client` e `curriculum`. Questo è il valore che sarà usato nel file `.env` più tardi.
- `i18nextCodes`: questi sono i codici ISO per le varie lingue. Dovrai aggiungere il codice ISO appropriato per la lingua che stai attivando. Questi devono essere unici per ogni lingua.
- `langDisplayNames`: Questi sono i nomi delle lingue visualizzati nel menù di navigazione.
- `langCodes`: Questi sono i codici delle lingue usati per formattare date e numeri. Questi devono essere codici Unicode CLDR invece di codici ISO.
Per esempio, se vuoi attivare la lingua Dothraki, il tuo oggetto `all-langs.js` dovrebbe essere come segue:
```js
const availableLangs = {
client: ['english', 'espanol', 'chinese', 'chinese-traditional', 'dothraki'],
curriculum: ['english', 'espanol', 'chinese', 'chinese-traditional', 'dothraki']
};
const i18nextCodes = {
english: 'en',
espanol: 'es',
chinese: 'zh',
'chinese-traditional': 'zh-Hant',
'dothraki': 'mis',
};
const langDisplayNames = {
english: 'English',
espanol: 'Español',
chinese: '中文（简体字）',
'chinese-traditional': '中文（繁體字）',
'dothraki': 'Dothraki',
};
const langCodes = {
english: 'en-US',
espanol: 'es-419',
chinese: 'zh',
'chinese-traditional': 'zh-Hant',
'dothraki': 'mis',
};
```
Successivamente, apri il file `client/src/utils/algolia-locale-setup.js`. Questi dati sono usati dalla barra di ricerca che carica gli articoli in `/news`. Anche se è poco probabile che tu stia testando questa funzione, se questi dati mancano per la tua lingua possono esserci degli errori nel costruire il codebase localmente.
Aggiungi un oggetto per la tua lingua all'oggetto `algoliaIndices`. Dovresti usare i valori dell'oggetto `english` per testare in locale, sostituiendo la chiave `english` con il valore della tua lingua in `availableLangs`.
Se volessi aggiungere Dothraki:
```js
const algoliaIndices = {
english: {
name: 'news',
searchPage: 'https://www.freecodecamp.org/news/search/'
},
espanol: {
name: 'news-es',
searchPage: 'https://www.freecodecamp.org/espanol/news/search/'
},
chinese: {
name: 'news-zh',
searchPage: 'https://chinese.freecodecamp.org/news/search/'
},
'chinese-traditional': {
name: 'news-zh',
searchPage: 'https://chinese.freecodecamp.org/news/search'
},
dothraki: {
name: 'news',
searchPage: 'https://www.freecodecamp.org/news/search/'
},
};
```
Quindi, devi dire al client quali certificazioni sono tradotte e quali sono ancora in inglese. Apri il file `utils/is-audited.js`. Aggiungi a `auditedCerts` una nuova chiave con il valore della tua lingua in `availableLangs`. Assegna a quella chiave un array contenente i *nomi con trattino* per le certificazioni che sono state tradotte. Riferisciti ai dati esistenti per i nomi con trattino.
Continuando il lavoro per attivare Dothraki, abbiamo tradotto le prime tre certificazioni:
```js
const auditedCerts = {
espanol: [
'responsive-web-design',
'javascript-algorithms-and-data-structures'
],
chinese: [
'responsive-web-design',
'javascript-algorithms-and-data-structures',
'front-end-libraries',
'data-visualization',
'apis-and-microservices',
'quality-assurance'
],
'chinese-traditional': [
'responsive-web-design',
'javascript-algorithms-and-data-structures',
'front-end-libraries',
'data-visualization',
'apis-and-microservices',
'quality-assurance'
],
'dothraki': [
'responsive-web-design',
'javascript-algorithms-and-data-structures',
'front-end-libraries'
]
};
```
Infinine, nel file `.env`, dai a `CLIENT_LOCALE` e `CURRICULUM_LOCALE` il valore della tua nuova lingua (usando il valore in `availableLangs`.)
```txt
CLIENT_LOCALE="dothraki"
CURRICULUM_LOCALE="dothraki"
```
## Caricare le traduzioni
Poiché la lingua non è ancora stata approvata per la produzione, i nostri script ancora non scaricheranno automaticamente le traduzioni. Solo lo staff ha accesso al download diretto delle traduzioni - sei il benvenuto a rivolgerti a noi attraverso la [chat room per i contributori](https://chat.freecodecamp.org/channel/contributors), o puoi tradurre i file markdown inglesi per le esigenze di test.
Una volta che avrai i file, li dovrai mettere nelle cartelle giuste. Per le sfide del curriculum, dovresti mettere le cartelle dei certificati (ad esempio `01-responsive-web-design`) nella cartella `curriculum/challenges/{lang}`. Per la nostra traduzione in Dothraki, questo sarebbe `curriculum/challenges/dothraki`. I file `.json` con le traduzioni del client vanno nella cartella `client/i18n/locales/{lang}`.
Una volta che questi saranno in posizione, dovresti essere in grado di eseguire `npm run develop` per vedere la versione tradotta di freeCodeCamp.
> [!ATTENTION] Anche se puoi farei delle traduzioni localmente per i test, ricordiamo che le traduzioni *non* devono essere inviate attraverso GitHub ma solo tramite Crowdin. Assicurati di resettare il tuo codebase locale dopo che avrai finito con i test.

148
docs/i18n/italian/how-to-translate-files.md Normal file
View File

@ -0,0 +1,148 @@
# Come tradurre le risorse di freeCodeCamp
Abbiamo il sogno di offrirti le risorse per imparare, non importa in che lingua del mondo tu parli. Per aiutarci con questo enorme sforzo, abbiamo integrato il nostro codebase open-source e il nostro curriculum con [Crowdin](https://crowdin.com/), uno strumento per aiutarci nella localizzazzione (cioè la traduzione nei vari "locale") del codebase.
Il workflow della traduzione è diviso in due attività principali:
- **Tradurre** i file del curriculum, la documentazione ed elementi dell'interfaccia come pulsanti, etichette, ecc.:
Come traduttore puoi iscriverti alla [nostra piattaforma di traduzione](https://translate.freecodecamp.org) e contribuire a tradurre in una qualsiasi delle oltre 30 lingue disponibili sulla piattaforma.
- **Revisionare** (Proofread) le traduzioni per gli elementi nominati in precedenza.
I revisori verificano che le traduzioni contribuite dalla community abbiano un tono uniforme e non abbiano problemi comuni come errori di spelling, ecc. In breve, si occupano di assicurare un'alta qualità della traduzione. Nota che non usiamo traduzioni automatiche per una ragione.
> [!WARNING] Non stiamo più usando GitHub per tradurre i file direttamente, se sei un contributore di vecchia data dirigiti invece alla [piattaforma di traduzione](https://translate.freecodecamp.org/).
## Preparati a contribuire
> La mappa per la localizzazione di freeCodeCamp – Non ci sono limiti di velocità
Puoi tradurre quanto vuoi, quando vuoi. È solo una questione di quanto tempo ed energie vuoi investire come traduttore volontario.
Chiediamo solo che tu comprenda i seguenti punti:
1. **Le traduzioni sono uno sforzo di gruppo.**
Tradurre le risorse di freeCodeCamp è una delle esperienze più divertenti e gratificanti come contributore, e funziona meglio se coivolgi i tuoi amici e colleghi che parlano la tua stessa lingua.
Raccomandiamo di unirti al [forum della community](https://forum.freecodecamp.org/c/contributors/3) e alla [chat room dei contributori](https://chat.freecodecamp.org/channel/contributors) con i tuoi amici e mostrare il tuo interesse prima di iniziare a tradurre. Crowdin rende più facile contribuire alle traduzioni, ma richiede comunque un sacco di lavoro.
Vogliamo che ti diverta a contribuire e che tu non soffra di burnout o perda interesse.
Un piccolo gruppo di 4-5 persone è una buona dimensione per iniziare la nicchia per la tua lingua. Puoi quindi reclutare ancora più amici perché si uniscano alla squadra.
2. **Costa un sacco creare i server per ogni lingua.**
In superficie lo stack tecnico può non sembrare complicato, ma costa un sacco tenere i motori in funzione. Questo include mettere in piedi server aggiuntivi e dedicare personale a controllarli.
freeCodeCamp.org si impegna a offrire queste cose gratuitamente come sempre, ma dobbiamo dare priorità alle risorse per chi ne ha più bisogno. L'ultima cosa che vogliamo è dover disattivare i server per una lingua se l'attività di traduzione si ferma e il materiale diventa obsoleto.
Una volta che una lingua raggiunge almeno alcune certificazioni del curriculum possiamo iniziare a mettere la lingua live su [`/learn`](https://www.freecodecamp.org/learn), mentre continuate a tradurre le restanti certificazioni.
Per esempio, vorremmo fare il deploy almeno di tutte le certificazioni front-ent quando attiviamo una nuova lingua per la prima volta.
3. **E per le lingue non elencate sulla piattaforma di traduzione?**
Abbiamo analizzato la nostra user base e aggiunto le 30+ lingue più usate alla lista delle lingue disponibili sulla piattaforma di traduzione. Al momento alcune lingue come cinese, spagnolo e italiano sono già disponibili live su **"/learn"**.
Sfortunatamente, la lista non include centinaia di lingue esistenti. Abbiamo dozzine di richieste da contributori come te ogni giorno che vogliono aiutare a tradurre il sito in una lingua che parlano.
Vogliamo decisamente aggiungere più lingue alla lista, ma come puoi già indovinare, questo è fattibile soltanto se raggiungiamo un sufficiente momento per una certa lingua.
Se vuoi includere una nuova lingua, ti raccomandiamo di entusiasmare i tuoi amici.
Una volta che avrai un piccolo gruppo di persone (almeno 4-5) interessate e volenterose a impegnarsi, potremo fare una videochiamata. Spiegheremo tutti i dettagli e vi guideremo nell'uso degli strumenti e sui processi.
## Iniziare
Come prima cosa, assicurati di venire a presentarti nella [chat room dei contributori](https://chat.freecodecamp.org/channel/contributors). Postiamo aggiornamenti regolari sulla traduzione delle risorse e rispondiamo a un sacco delle vostre domande lì.
Poi, vai alla nostra [piattaforma di traduzione](https://translate.freecodecamp.org/) e fai login (se è la prima volta che contribuisci alle traduzioni, dovrai creare un account).
Infine, segui la guida dettagliata qua sotto per capire come funzionano gli strumenti di traduzione e il workflow a tua disposizione.
Buona traduzione.
## Selezionare un progetto e un file
Quando visiti la piattaforma di traduzione, dovresti vedere vari °progetti° disponibili per la traduzione:
1. Il progetto della [documentazione per contribuire (Contributing documentation)](https://translate.freecodecamp.org/contributing-docs) che contiene i file per questo sito di documentazione.
2. Il progetto del [Coding Curriculum](https://translate.freecodecamp.org/curriculum), che contiene i file delle sfide del curriculum per programmatori.
3. Il progetto dell'[interfaccia della piattaforma di apprendimento (Learn User Interface)](https://translate.freecodecamp.org/learn-ui), che contiene le stringhe per gli elementi dell'interfaccia come pulsanti, etichette, ecc.
Seleziona il progetto a cui vuoi contribuire, e vedrai una lista con le lingue disponibili per la traduzione.
![Immagine - Lista delle lingue disponibili](https://contribute.freecodecamp.org/images/crowdin/languages.png)
Seleziona la lingua su cui vuoi lavorare, e vedrai l'albero dei file completo.
![Immagine - Lista dei file disponibili](https://contribute.freecodecamp.org/images/crowdin/file-tree.png)
Ogni file e cartella mostrerà una barra di avanzamento. La parte **blu** della barra di avanzamento indica che percentuale del file è stata tradotta, mentre la parte **verde** indica quale percentuale del file è stata approvata dal team di revisione.
Seleziona un file su cui lavorare e Crowdin aprirà l'editor.
> [!NOTE] Quando l'editor si apre, dovrai cliccare sull'icona delle impostazioni (ha la forma di un ingranaggio) e mettere l'opzione 'HTML tags displaying' (mostrare i tag HTML) su 'SHOW' (mostra). Questo fa in modo che tu possa vedere i tag come `<code></code>` invece di `<0></0>`.
## Tradurre il curriculum
![Immagine - Editor View](https://contribute.freecodecamp.org/images/crowdin/editor.png)
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.
![Immagine - Messaggio di errore del controllo qualità](https://contribute.freecodecamp.org/images/crowdin/qa-message.png)
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 `<code>` 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 `<code>`. 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.

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

@ -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.

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

@ -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.
[![Apri in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](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
<div>example code</div>
````
# --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
<body>
<p class="main-text">Hello world!</p>
</body>
```
```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 (
<div>
{/* Change code below this line */}
<button>Click Me</button>
{/* Change code above this line */}
<h1>{this.state.text}</h1>
</div>
);
}
}
```
### 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
<details><summary>Solution 1 (Click to Show/Hide)</summary>
```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)
</details>
````
## 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.

267
docs/i18n/italian/how-to-work-on-localized-client-webapp.md Normal file
View File

@ -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:
<p>{t('key')}</p>; // 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:
<h1>{t('key')}</h1> // 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:
<p>{t('p1')}</p>
// nel file JSON:
{
"p1": "My paragraph"
}
// output:
<p>My paragraph</p>
```
### Con dati dinamici
```js
// nel componente:
const username = 'moT';
<p>{t('welcome', { username: username })}</p>
// nel file JSON:
{
"welcome": "Welcome {{username}}"
}
// output:
<p>Welcome moT</p>
```
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'
<p>
<Trans>fcc.greeting</Trans>
</p>
// nel file JSON:
{
"fcc": {
"greeting": "Welcome to <strong>freeCodeCamp</strong>"
}
}
// output:
<p>Welcome to <strong>freeCodeCamp</strong></p>
```
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:
<p>
<Trans i18nKey='check-forum'>
<a href='https://forum.freecodecamp.org/'>placeholder</a>
</Trans>
</p>
// nel file JSON:
{
"check-forum": "Check out <0>our forum</0>."
}
// output:
<p>Check out <a href='https://forum.freecodecamp.org/'>our forum</a></p>
```
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 `<a>` lasciato vuoto.
### Con una variabile
```js
// nel componente:
const email = 'team@freecodecamp.org';
<p>
<Trans email={email} i18nKey='fcc.email'>
<a href={`mailto:${email}`}>
{{ email }}
</a>
</Trans>
</p>
// nel file JSON:
{
"fcc": {
"email": "Send us an email at: <0>{{email}}</0>"
}
}
// output:
<p>Send us an email at: <a href='mailto:team@freecodecamp.org'>team@freecodecamp.org</a><p>
```
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)

123
docs/i18n/italian/how-to-work-on-practice-projects.md Normal file
View File

@ -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
```

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

@ -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 <http://localhost:3200>

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

@ -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: <https://github.com/freeCodeCamp/news-theme>.
## 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/<theme-name>. 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.

49
docs/i18n/italian/index.md Normal file
View File

@ -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.**
[![Apri in Gipod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Oppure puoi...
**[eseguire freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md) nella tua macchina.**

540
docs/i18n/italian/moderator-handbook.md Normal file
View File

@ -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:
<details>
<summary>
Badge first time contributor sulle pull request (screenshot)
</summary>
<br>
<img src="https://i.imgur.com/dTQMjGM.png" alt="Badge first time contributor sulle pull request" />
</details>
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.
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
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.
```