From b19c629a64ffe9b3cde64b68093ffd7aa79103c2 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Fri, 30 Jul 2010 11:07:20 +0200
Subject: [PATCH 01/10] minor fixes

---
 ...8-Inside-the-Model-Layer-Doctrine.markdown |   2 +-
 gentle-introduction/it/10-Forms.markdown      | 339 +++++++++---------
 .../16-Application-Management-Tools.markdown  |  34 +-
 .../it/17-Extending-Symfony.markdown          |  30 +-
 4 files changed, 203 insertions(+), 202 deletions(-)
 mode change 100755 => 100644 gentle-introduction/it/10-Forms.markdown

diff --git a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
index b17c139..53631d1 100644
--- a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
+++ b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
@@ -824,7 +824,7 @@ Si può usare il file `schema.sql` direttamente per costruire le tabelle. Ad ese
     $ mysqladmin -u root -p create blog
     $ mysql -u root -p blog < data/sql/schema.sql
 
-L'SQL generato è utile anche per ricostruire il database in un altro ambiente o per passare ad un altro DBMS.
+L'SQL generato è utile anche per ricostruire il database in un altro ambiente o per passare a un altro DBMS.
 
 >**TIP**
 >La riga di comando offre anche un task per popolare il database con i dati caricati da un file di testo. Vedere il capitolo 16 per maggiori informazioni sul task `doctrine:data-load` e i file delle fixture in YAML.
diff --git a/gentle-introduction/it/10-Forms.markdown b/gentle-introduction/it/10-Forms.markdown
old mode 100755
new mode 100644
index 7979ded..41b2ecb
--- a/gentle-introduction/it/10-Forms.markdown
+++ b/gentle-introduction/it/10-Forms.markdown
@@ -1,19 +1,19 @@
-Chapter 10 - I Form
-==================
+Chapter 10 - I form
+===================
 
 La visualizzazione degli input di un form, la validazione dei dati inseriti in un form e tutta la casistica particolare del trattamento dei form è uno dei compiti più complessi nello sviluppo web. Fortunatamente, symfony fornisce un'interfaccia semplice verso un potente sottosistema dedicato ai form, e facilita la creazione e la manipolazione con poche linee di codice di form di qualsiasi livello di complessità.
 
 Visualizzazione di un form
------------------
+--------------------------
 
 Un semplice form di contatto con dei campi nome, email, oggetto e messaggio tipicamente appare come segue:
 
 ![Form di contatto](http://www.symfony-project.org/images/forms_book/en/01_07.png)
 
-In symfony un form è un oggetto definito nell'action e passato al template. Prima di visualizzare un form, si devono definire i campi che esso contiene, ossia quelli che con la terminologia propria di symfony vengono chiamati "widget". Il modo più semplice per farlo è di creare un nuovo oggetto "sfForm" nell'opportuno metodo dell'action.
+In symfony un form è un oggetto definito nell'azione e passato al template. Prima di visualizzare un form, si devono definire i campi che esso contiene, ossia quelli che con la terminologia propria di symfony vengono chiamati "widget". Il modo più semplice per farlo è di creare un nuovo oggetto `sfForm` nell'opportuno metodo dell'action.
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     public function executeContact($request)
     {
       $this->form = new sfForm();
@@ -25,15 +25,15 @@ In symfony un form è un oggetto definito nell'action e passato al template. Pri
       ));
     }
 
-`sfForm::setWidgets()` si attende un array associativo di nomi di widtget / oggetti widget. `sfWidgetFormInputText`, `sfWidgetFormChoice`, e `sfWidgetFormTextarea` sono alcune delle numerose classi di widget offerte da symfony; se ne può trovare una lista completa più avanti in questo capitolo.
+`sfForm::setWidgets()` si aspetta un array associativo di nomi di widtget / oggetti widget. `sfWidgetFormInputText`, `sfWidgetFormChoice` e `sfWidgetFormTextarea` sono alcune delle numerose classi di widget offerte da symfony; se ne può trovare una lista completa più avanti in questo capitolo.
 
-L'esempio precedente mostra due opzioni dei widget che è possibile usare: "default" imposta il valore da assegnare al widget, ed è disponibile per tutti i tipi di widget. "choices" è invece un'opzione specifica dei widget di tipo "choice" (che viene visualizzato come una lista a discesa): essa definisce le opzioni selezionabili dall'utente.
+L'esempio precedente mostra due opzioni dei widget che è possibile usare: `default` imposta il valore da assegnare al widget ed è disponibile per tutti i tipi di widget. `choices`è invece un'opzione specifica dei widget di tipo `choice` (che viene visualizzato come una lista a discesa): essa definisce le opzioni selezionabili dall'utente.
 
-Dunque l'azione "foo/contact" definisce un oggetto form, che rende disponibile al template "contactSuccess" in una variabile "$form".  Il template può usare questo oggetto per generare le varie parti del form in HTML. Il modo più semplice per farlo è una chiamata del tipo "echo $form", che costruisce tutti i campi come controlli del form con etichette. Si può anche usare l'oggetto form per generare il tag form:
+Dunque l'azione `pippo/contact` definisce un oggetto form, che rende disponibile al template `contactSuccess` in una variabile `$form`.  Il template può usare questo oggetto per generare le varie parti del form in HTML. Il modo più semplice per farlo è una chiamata del tipo `echo $form`, che costruisce tutti i campi come controlli del form con etichette. Si può anche usare l'oggetto form per generare il tag form:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
       <table>
         <?php echo $form ?>
         <tr>
@@ -47,7 +47,7 @@ Dunque l'azione "foo/contact" definisce un oggetto form, che rende disponibile a
 Con i parametri passati a setWidgets(), symfony ha informazioni sufficienti per mostrare il form correttamente. L'HTML risultante, corrispondente allo screenshot visto in precedenza, appare come segue:
 
     [php]
-    <form action="/frontend_dev.php/foo/contact" method="POST">
+    <form action="/frontend_dev.php/pippo/contact" method="POST">
       <table>
         <tr>
           <th><label for="name">Name</label></th>
@@ -79,16 +79,16 @@ Con i parametri passati a setWidgets(), symfony ha informazioni sufficienti per
       </table>
     </form>
 
-Ogni widget viene convertito nella riga di una tabella contenente un tag <label> e un tag di input del form. Symfony deduce il nome della label dal nome del widget, convertendo l'iniziale in maiuscolo (il nome del widget "subject" dà la label "Subject"). Per quanto riguarda il tag di input, esso dipende dal tipo di widget. Symfony aggiunge un attributo "id" ad ogni widget, basandolo sul suo nome. Infine, la resa del form è sempre conforme alle specifiche XHTML.
+Ogni widget viene convertito nella riga di una tabella contenente un tag <label> e un tag di input del form. Symfony deduce il nome della label dal nome del widget, convertendo l'iniziale in maiuscolo (il nome del widget `subject` dà la label `Subject`). Per quanto riguarda il tag di input, esso dipende dal tipo di widget. Symfony aggiunge un attributo `id` ad ogni widget, basandolo sul suo nome. Infine, la resa del form è sempre conforme alle specifiche XHTML.
 
 Personalizzare la visualizzazione del form
-----------------------------
+------------------------------------------
 
-L'uso di "echo $form" è ottimo per la prototipazione, ma probabilmente si desidera controllare esattamente il codice HTML risultante. L'oggetto form contiene un array di campi, e la chiamata "echo $form" di fatto itera attraverso i campi e li genera uno per uno. Per avere un controllo ulteriore, è possibile iterare manualmente attraverso i campi, e richiamare "renderRow()" per ogni campo. Il listato che segue produce esattamente lo stesso codice HTML del precedente, ma il template scrive ogni campo individualmente:
+L'uso di `echo $form` è ottimo per la prototipazione, ma probabilmente si desidera controllare esattamente il codice HTML risultante. L'oggetto form contiene un array di campi, e la chiamata `echo $form` di fatto itera attraverso i campi e li genera uno per uno. Per avere un controllo ulteriore, è possibile iterare manualmente attraverso i campi, e richiamare `renderRow()` per ogni campo. Il listato che segue produce esattamente lo stesso codice HTML del precedente, ma il template scrive ogni campo individualmente:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
       <table>
         <?php echo $form['name']->renderRow() ?>
         <?php echo $form['email']->renderRow() ?>
@@ -102,13 +102,13 @@ L'uso di "echo $form" è ottimo per la prototipazione, ma probabilmente si desid
       </table>
     </form>
 
-Generare i campi uno alla volta permette di cambiare l'ordine nel quale essi sono visualizzati, e inoltre di personalizzare il loro aspetto. "renderRow()" aspetta una lista di attributi HTML come primo argomento, così è possibile definire una classe, un id o l'handler JavaScript di un evento per ogni istanza. Il secondo argomento di "render Row()" è una label opzionale che sovrascrive quella dedotta dal nome del widget. Segue un esempio di personalizzazione del form di contatto:
+Generare i campi uno alla volta permette di cambiare l'ordine nel quale essi sono visualizzati, e inoltre di personalizzare il loro aspetto. `renderRow()` si aspetta una lista di attributi HTML come primo parametro, così è possibile definire una classe, un id o l'handler JavaScript di un evento per ogni istanza. Il secondo parametro di `render Row()` è una label opzionale che sovrascrive quella dedotta dal nome del widget. Segue un esempio di personalizzazione del form di contatto:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
       <table>
-        <?php echo $form['name']->renderRow(array('size' => 25, 'class' => 'foo'), 'Your Name') ?>
+        <?php echo $form['name']->renderRow(array('size' => 25, 'class' => 'pippo'), 'Your Name') ?>
         <?php echo $form['email']->renderRow(array('onclick' => 'this.value = "";'), 'Your Email') ?>
         <?php echo $form['message']->renderRow() ?>
         <tr>
@@ -119,11 +119,11 @@ Generare i campi uno alla volta permette di cambiare l'ordine nel quale essi son
       </table>
     </form>
 
-A volte può essere necessario produrre le label e l'input di ogni campo in una lista con tag <li> anziché in una tabella con tag <tr>. Un campo "row" è costituito da una label, un messaggio di errore opzionale (aggiunto dal sistema di validazione spiegato nel seguito di questo capitolo), un testo di help e un widget (si noti che il widget può consistere di più di un controllo form). Così com'è possibile produrre i vari campi di un form uno per uno, è anche possibile rendere le varie parti di un form indipendentemente. Anziché usare renderRow(), si può scegliere di usare render() (per il widget), renderError(), renderLabel e renderHelp(). Ad esempio, se si desidera generare tutto il form con tag <li>, si scriva il template come segue:
+A volte può essere necessario produrre le label e l'input di ogni campo in una lista con tag `<li>` anziché in una tabella con tag `<tr>`. Un campo "riga" è costituito da una label, un messaggio di errore opzionale (aggiunto dal sistema di validazione spiegato nel seguito di questo capitolo), un testo di help e un widget (si noti che il widget può consistere di più di un controllo form). Così com'è possibile produrre i vari campi di un form uno per uno, è anche possibile rendere le varie parti di un form indipendentemente. Anziché usare renderRow(), si può scegliere di usare render() (per il widget), `renderError()`, `renderLabel` e `renderHelp()`. Ad esempio, se si desidera generare tutto il form con tag `<li>`, si scriva il template come segue:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
       <ul>
         <?php foreach ($form as $field): ?>
         <li>
@@ -140,7 +140,7 @@ A volte può essere necessario produrre le label e l'input di ogni campo in una
 L'HTML generato è il seguente:
 
     [php]
-    <form action="/frontend_dev.php/foo/contact" method="POST">
+    <form action="/frontend_dev.php/pippo/contact" method="post">
       <ul>
         <li>
           <label for="name">Name</label>
@@ -169,11 +169,11 @@ L'HTML generato è il seguente:
     </form>
 
 >**TIP**
->Una "field row" è la rappresentazione di tutti gli elementi di un campo form (label, messaggio di errore, testo di help, form input) usando un formattatore. Per default, symfony usa un formattatore "tabella", e questo è il motivo per cui renderRow() restituisce un insieme di tag <tr>, <th> e <td>. Alternativamente, è possibile ottenere lo stesso codice HTML di cui sopra semplicemente specificando il formattatore alternativo "list" per il form, come segue:
+>Il campo di una riga è la rappresentazione di tutti gli elementi di un campo form (label, messaggio di errore, testo di help, form input) usando un formattatore. Per default, symfony usa un formattatore "tabella", e questo è il motivo per cui `renderRow()` restituisce un insieme di tag `<tr>`, `<th>` e `<td>`. Alternativamente, è possibile ottenere lo stesso codice HTML di cui sopra semplicemente specificando il formattatore alternativo "list" per il form, come segue:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
       <ul>
         <?php echo $form->renderUsing('list') ?>
         <li>
@@ -185,31 +185,31 @@ L'HTML generato è il seguente:
 -
 
 >**TIP**
->Fare riferimento alla documentazione delle API per la classe sfWidgetFormSchemaFormatter per imparare come creare un proprio formattatore.
+>Fare riferimento alla documentazione delle API per la classe `sfWidgetFormSchemaFormatter` per imparare come creare un proprio formattatore.
 
-I Form Widgets
-------------
+I widget dei form
+-----------------
 
-Ci sono molti form widgets disponibili per comporre i propri form. Tutti i widget accettano come minimo l'opzione "default".
+Ci sono molti widget di form disponibili per comporre i propri form. Tutti i widget accettano come minimo l'opzione `default`.
 
 Per un widget è anche possibile definire la label e tutti gli attributi HTML, quando si crea il form:
 
     [php]
     $this->form = new sfForm();
     $this->form->setWidgets(array(
-      'name'    => new sfWidgetFormInput(array('label' => 'Your Name'), array('size' => 25, 'class' => 'foo')),
+      'name'    => new sfWidgetFormInput(array('label' => 'Your Name'), array('size' => 25, 'class' => 'pippo')),
       'email'   => new sfWidgetFormInput(array('default' => 'me@example.com', 'label' => 'Your Email'), array('onclick' => 'this.value = "";')),
       'subject' => new sfWidgetFormChoice(array('choices' => array('Subject A', 'Subject B', 'Subject C'))),
       'message' => new sfWidgetFormTextarea(array(), array('rows' => '20', 'cols' => 5)),
     ));
 
-Symfony usa questi parametri per mostrare il widget, ma è ancora possibile sovrascriverli passando dei parametri personalizzati a renderRow() nel template.
+Symfony usa questi parametri per mostrare il widget, ma è ancora possibile sovrascriverli passando dei parametri personalizzati a `renderRow()` nel template.
 
->**TIP**: Come alternativa alla chiamata di setWidgets() con un array associativo, è possibile chiamare più volte setWidget($nome, $widget).
+>**TIP**: Come alternativa alla chiamata di `setWidgets()` con un array associativo, è possibile chiamare più volte `setWidget($nome, $widget)`.
 
-### I Widget standard
+### I widget standard
 
-Nel seguito viene presentata una lista dei tipi di widget disponibili, e di come essi vengono tradotti in HTML attraverso renderRow():
+Nel seguito viene presentata una lista dei tipi di widget disponibili, e di come essi vengono tradotti in HTML attraverso `renderRow()`:
 
     [php]
     // Text input
@@ -242,19 +242,19 @@ Ci sono altre opzioni disponibili per ogni widget: fare riferimento alla documen
 
 ### Widget di tipo lista
 
-Ogni volta che gli utenti devono fare una scelta tra una lista di valori, e se essi possono selezionare una o più opzioni in questa lista, un singolo widget risponde a tutte le esigenze: il widget "choice". 
-In base alle impostazioni di due parametri opzionali ("multiple" e "expanded"), questo widget genera l'HTML in maniera differente:
+Ogni volta che gli utenti devono fare una scelta tra una lista di valori, e se essi possono selezionare una o più opzioni in questa lista, un singolo widget risponde a tutte le esigenze: il widget `choice`. 
+In base alle impostazioni di due parametri opzionali (`multiple` e `expanded`), questo widget genera l'HTML in maniera differente:
 
-                      | multiple=false       | multiple=true
-                      | (default)            |
-      ----------------|----------------------|---------------------
-      expanded=false  |    Dropdown list     |    Dropdown box
-      (default)       |    (`<select>`)      | (`<select multiple>`)
-      ----------------|----------------------|----------------------
+                      | multiple=false        | multiple=true
+                      | (default)             |
+      ----------------|-----------------------|---------------------
+      expanded=false  |    Dropdown list      |    Dropdown box
+      (default)       |    (`<select>`)       | (`<select multiple>`)
+      ----------------|-----------------------|----------------------
       expanded=true   | Lista di Radiobuttons | Lista di checkboxes
-                      |                      |
+                      |                       |
 
-Il widget "choice" si attende come minimo un parametro "choices" costituito da un array associativo che definisca il valore e il testo di ogni opzione. Segue un esempio per ogni sintassi:
+Il widget `choice` si attende come minimo un parametro `choices` costituito da un array associativo che definisca il valore e il testo di ogni opzione. Segue un esempio per ogni sintassi:
 
     [php]
     // Dropdown list (select)
@@ -312,34 +312,34 @@ Il widget "choice" si attende come minimo un parametro "choices" costituito da u
       <li><input type="checkbox" name="interests[]" id="interests_1" value="1"><label for="interests_1">Altro</label></li>
     </ul>
 
->**Tip**: Si noti che symfony definisce automaticamente un attributo 'id' per ogni input del form, basato su una combinazione del nome e del valore del widget. E' possibile sovrascrivere l'attributo 'id' widget per widget, o alternativamente settare una regola globale per l'intero form usando il metodo 'setIdFormat()':
+>**Tip**: Si noti che symfony definisce automaticamente un attributo `id` per ogni input del form, basato su una combinazione del nome e del valore del widget. È possibile sovrascrivere l'attributo `id` widget per widget, o alternativamente impostare una regola globale per l'intero form usando il metodo 'setIdFormat()':
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     $this->form = new sfForm();
     $this->form->setIdFormat('my_form_%s');
 
 ### I widget per le Foreign Keys
 
-Quando si editano gli oggetti del modello attraverso un form, si presenta sempre una particolare lista di scelte: la lista di oggetti che possono essere messi in relazione con quello corrente. Questo accade quando i modelli sono in relazione molti-a-uno o molti-a-molti. Fortunatamente, il plugin 'sfPropelPlugin' distribuito insieme a symfony offre un widget `sfWidgetFormPropelChoice` utile proprio in questi casi (e naturalmente 'sfDoctrinePlugin' offre un analogo widget `sfWidgetFormDoctrineChoice`).
+Quando si modificano gli oggetti del modello attraverso un form, si presenta sempre una particolare lista di scelte: la lista di oggetti che possono essere messi in relazione con quello attuale. Questo accade quando i modelli sono in relazione uno-a-molti o molti-a-molti. Fortunatamente, il plugin `sfPropelPlugin` distribuito insieme a symfony, offre un widget `sfWidgetFormPropelChoice` utile proprio in questi casi (e naturalmente `sfDoctrinePlugin` offre un analogo widget `sfWidgetFormDoctrineChoice`).
 
-Ad esempio, se una 'Sezione' ha molti 'Articoli', si dovrebbe essere in grado di scelte una sezione tra quelle esistenti quando si edita un articolo. Per fare questo, un "FormArticolo" dovrebbe usare il widget `sfWidgetFormPropelChoice`:
+Ad esempio, se una `Section` ha molti `Articles`, si dovrebbe essere in grado di scelte una sezione tra quelle esistenti quando si edita un articolo. Per fare questo, un `ArticleForm` dovrebbe usare il widget `sfWidgetFormPropelChoice`:
 
     [php]
-    $formArticolo = new sfForm();
-    $formArticoli->setWidgets(array(
+    $articleForm = new sfForm();
+    $articleForm->setWidgets(array(
       'id'        => sfWidgetFormInputHidden(),
-      'titolo'     => sfWidgetFormInputText(),
-      'id_sezione' => sfWidgetFormPropelChoice(array(
-        'model'  => 'Sezione',
-        'column' => 'nome'
+      'title'     => sfWidgetFormInputText(),
+      'section_id' => sfWidgetFormPropelChoice(array(
+        'model'  => 'Section',
+        'column' => 'name'
       )
     )));
 
-Questo mostra una lista delle sezioni esistenti... purché si sia definito un metodo '__toString()' nella classe del modello "Sezione". Questo perché symfony prima richiama gli oggetti 'Sezione' disponibili, e popola un widget 'choice' con essi tentando di convertirli in stringa con __toString(). Il modello "Sezione" dunque dovrebbe definire almeno il seguente metodo:
+Questo mostra una lista delle sezioni esistenti... purché si sia definito un metodo `__toString()` nella classe del modello `Section`. Questo perché symfony prima richiama gli oggetti `Section` disponibili, e popola un widget `choice` con essi, tentando di convertirli in stringa con `__toString()`. Il modello `Section` dunque dovrebbe definire almeno il seguente metodo:
 
     [php]
-    // in lib/model/Sezione.php
+    // in lib/model/Section.php
     public function __toString()
     {
       return $this->getName();
@@ -347,14 +347,14 @@ Questo mostra una lista delle sezioni esistenti... purché si sia definito un me
 
 Il widget `sfWidgetFormPropelChoice` è un'estensione del widget `sfWidgetFormChoice`, così è possibile usare l'opzione 'multiple' per trattare le relazioni molti-a-molti, e l'opzione 'expanded' per cambiare il modo in cui il widget è reso.
 
-Se si desidera ordinare la lista di scelte in un modo particolare, o filtrarle in modo da mostrare solo una porzione delle scelte disponibili, è possibile usare l'opzione 'criteria' per passare un oggetto 'Criteria' al widget. Doctrine supporta lo stesso tipo di personalizzazione: è possibile passare un oggetto 'Doctrine_Queryì al widget con l'opzione 'query'.
+Se si desidera ordinare la lista di scelte in un modo particolare o filtrarle in modo da mostrare solo una porzione delle scelte disponibili, è possibile usare l'opzione `criteria` per passare un oggetto `Criteria` al widget. Doctrine supporta lo stesso tipo di personalizzazione: è possibile passare un oggetto `Doctrine_Query` al widget con l'opzione `query`.
 
-### I Widgets per le date
+### I widget per le date
 
-I widget Date e tine restituiscono un insieme di liste drop-down, popolate con i valori disponibili per il giorno, il mese, l'anno, l'ora o il minuto.
+I widget per data e ora restituiscono un insieme di liste drop-down, popolate con i valori disponibili per il giorno, il mese, l'anno, l'ora o il minuto.
 
     [php]
-    // Date
+    // Data
     $years = range(1950, 1990);
     $form->setWidget('ddn', new sfWidgetFormDate(array(
       'label'   => 'Data di nascita',
@@ -385,7 +385,7 @@ I widget Date e tine restituiscono un insieme di liste drop-down, popolate con i
       <option value="1990">1990</option>
     </select>
     
-    // Time
+    // Ora
     $form->setWidget('start', new sfWidgetFormTime(array('default' => '12:00')));
     // symfony rende il widget in HTML come segue:
     <label for="start">Start</label>
@@ -405,20 +405,20 @@ I widget Date e tine restituiscono un insieme di liste drop-down, popolate con i
       <option value="59">59</option>
     </select>
 
-    // Date e time
+    // Data e ora
     $form->setWidget('end', new sfWidgetFormDateTime(array('default' => '01/01/2008 12:00')));
     // symfony rende il widget in HTML come 5 liste dropdown per mese, giorno,anno, ora e minuto
 
 Naturalmente, si può personalizzare il formato della data per mostrarla in stile Europeo anziché Internazionale (`%day%/%month%/%year%` invece di `%month%/%day%/%year%`), si può scegliere l'orario a 12 ore anziché 24, si possono definire valori personalizzati per la prima opzione di ogni dropdown box, e si possono definire limiti per i possibili valori. Ancora una volta, si rimanda alla documentazione delle API per maggiori dettagli riguardo le opzioni di questi widget.
 
-I widget Date sono un buon esempio della potenza dei widget in symfony. Un widget non è semplicemente l'input di un form. Esso può essere una combinazione di più input, che symfony può rendere e leggere in maniera trasparente.
+I widget data sono un buon esempio della potenza dei widget in symfony. Un widget non è semplicemente l'input di un form. Esso può essere una combinazione di più input, che symfony può rendere e leggere in maniera trasparente.
 
-### I widget I18n (Internationalization)
+### I widget I18n
 
-Nelle applicazioni multilingua, le date devono essere mostrare in un formato che si accordi con la cultura dell'utente (si veda il Capitolo 13 per dettagli riguardo cultura e localizzazione). Per facilitare questa licalizzazione nei form, symfony offre un widget `sfWidgetFormI18nDate`, che si basa sulla 'culture' dell'utente per stabilire i parametri di formattazione delle date. È anche possibile specificare un 'month_format' per visualizzare una lista drop-down con i nomi dei mesi (nella lingua dell'utente) invece dei numeri.
+Nelle applicazioni multilingua, le date devono essere mostrare in un formato che si accordi con la cultura dell'utente (si veda il Capitolo 13 per dettagli riguardo cultura e localizzazione). Per facilitare questa localizzazione nei form, symfony offre un widget `sfWidgetFormI18nDate`, che si basa sulla `culture` dell'utente per stabilire i parametri di formattazione delle date. È anche possibile specificare un `month_format` per visualizzare una lista drop-down con i nomi dei mesi (nella lingua dell'utente) invece dei numeri.
 
     [php]
-    // Date
+    // Data
     $years = range(1950, 1990);
     $form->setWidget('dob', new sfWidgetFormI18nDate(array(
       'culture'      => $this->getUser()->getCulture(),
@@ -450,11 +450,12 @@ Nelle applicazioni multilingua, le date devono essere mostrare in un formato che
     </select> /
     <select id="dob_year" name="dob[year]">...</select>
 
-Dei widget simili esistono per time (`sfWidgetFormI18nTime`) e datetime `sfWidgetFormI18nDateTime`).
+Dei widget simili esistono per ora (`sfWidgetFormI18nTime`) e data/ora `sfWidgetFormI18nDateTime`).
 
-Ci sono due liste drop-down che appaiono in molti form e che dipendono anch'essi dalla cultura: i selettori country e language. Symfony fornisce due widget specifici per questi scopi. Non sarà necessario definire le 'choices' in questi widget, in quanto symfony le popolerà con una lista di nazioni e linguaggi nel linguaggio dell'utente (purché l'utente parli una delle 250 lingue supportate da symfony).
+Ci sono due liste drop-down che appaiono in molti form e che dipendono anch'essi dalla cultura: i selettori di paese e di lingua. Symfony fornisce due widget specifici per questi scopi. Non sarà necessario definire le 'choices' in questi widget, in quanto symfony le popolerà con una lista di nazioni e lingue nella lingua dell'utente (purché l'utente parli una delle 250 lingue supportate da symfony).
 
-    // Country list
+    [php]
+    // Elenco di paesi
     $form->setWidget('country', new sfWidgetFormI18nCountryChoice(array('default' => 'UK')));
     // Per un utente di lingua inglese, symfony rende il widget in HTML come segue:
     <label for="country">Country</label>
@@ -466,7 +467,7 @@ Ci sono due liste drop-down che appaiono in molti form e che dipendono anch'essi
       <option value="ZWD">Zimbabwe</option>
     </select>
 
-    // Language list
+    // Elenco di lingue
     $form->setWidget('language', new sfWidgetFormI18nLanguageChoice(array(
       'languages' => array('en', 'fr', 'de'),  // optional restricted list of languages
       'default'   => 'en'
@@ -480,7 +481,7 @@ Ci sono due liste drop-down che appaiono in molti form e che dipendono anch'essi
       <option value="fr">French</option>
     </select>
 
-### I widget di tipo File
+### I widget di tipo file
 
 Trattare con gli input di tipo file non è più complicato che trattare con gli altri widget:
 
@@ -492,23 +493,23 @@ Trattare con gli input di tipo file non è più complicato che trattare con gli
     <input id="picture" type="file" name="picture"/>
     // Ogni volta che un form contiene un file widget, renderFormTag() restituisce un tag <form> con l'opzione multipart
     
-    // Editable input file
-    $form->setWidget('picture', new sfWidgetFormInputFileEditable(array('default' => '/images/foo.png')));
+    // Input file modificabile
+    $form->setWidget('picture', new sfWidgetFormInputFileEditable(array('default' => '/images/pippo.png')));
     // symfony rende il widget in HTML come un file input tag, insieme a una preview del file corrente
 
->**TIP**: Esistono molti widget addizionali forniti da plugin di terze parti. E' possibile trovare un widget rich text editor, un widget calendario, o altri widget 'rich UI' per varie librerie JavaScript. Sfoglia il [Plugins repository] (http://www.symfony-project.org/plugins/) per ulteriori dettagli.
+>**TIP**: Esistono molti widget addizionali forniti da plugin di terze parti. È possibile trovare un widget editor visuale, un widget calendario o altri widget 'rich UI' per varie librerie JavaScript. Consultare l'elenco dei [plugin](http://www.symfony-project.org/plugins/) per ulteriori dettagli.
 
-Trattare le richieste dei Form
-------------------------------
+Gestire le richieste dei form
+-----------------------------
 
-Quando gli utenti riempiono un form e lo inviano, il web application server deve recuperare i dati dalla richiesta e fare alcune cose con essi. La classe 'sfForm' fornisce tutti i metodi necessari per fare questo in un paio di linee di codice. 
+Quando gli utenti riempiono un form e lo inviano, il server deve recuperare i dati dalla richiesta e fare alcune cose con essi. La classe `sfForm` fornisce tutti i metodi necessari per fare questo in un paio di linee di codice. 
 
-### Trattamento semplice dei Form
+### Gestione semplice dei Form
 
-Dato che i widget restituiscono dei campi form HTML regolari, ricevere il loro valore nell'azione che tratta l'invio dei form è semplice quanto testare i relativi parametri della richiesta. Per il form di contatto di esempio, l'azione potrebbe essere scritta come segue:
+Dato che i widget restituiscono dei campi form HTML regolari, ricevere il loro valore nell'azione che tratta l'invio dei form è semplice: basta testare i relativi parametri della richiesta. Per il form di contatto di esempio, l'azione potrebbe essere scritta come segue:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     public function executeContact($request)
     {
       // Definizione del form
@@ -520,37 +521,37 @@ Dato che i widget restituiscono dei campi form HTML regolari, ricevere il loro v
         'messaggio' => new sfWidgetFormTextarea(),
       ));
 
-      // Trattamento della richiesta
+      // Gestione della richiesta
       if ($request->isMethod('post'))
       {
         // Gestisce l'invio del form
         $name = $request->getParameter('nome');
         // Fa quello che deve fare...
         // ...
-        $this->redirect('foo/bar');
+        $this->redirect('pippo/bar');
       }
     }
 
-Se il metodo della richiesta è 'GET', questa azione termina con un `sfView::SUCCESS`, quindi rende il template 'contactSuccess' per mostrare il form. Se il metodo della richiesta è 'POST', l'azione gestisce l'invio del form e reindirizza a un'altra azione. Perché questo funzioni, l'azione target del tag <form> dev'essere la stessa che sta mostrando il form. Questo spiega perché negli esempi precedenti è stato usato 'foo/contact' come target del form:
+Se il metodo della richiesta è `GET`, questa azione termina con un `sfView::SUCCESS`, quindi rende il template `contactSuccess` per mostrare il form. Se il metodo della richiesta è `POST`, l'azione gestisce l'invio del form e reindirizza a un'altra azione. Perché questo funzioni, l'azione target del tag `<form>` deve essere la stessa che sta mostrando il form. Questo spiega perché negli esempi precedenti è stato usato `pippo/contact` come target del form:
 
     [php]
-    // in modules/foo/templates/contactSuccess.php
-    <?php echo $form->renderFormTag('foo/contact') ?>
+    // in modules/pippo/templates/contactSuccess.php
+    <?php echo $form->renderFormTag('pippo/contact') ?>
     ...
 
-### Trattamento dei form con validazione dei dati
+### Gestione dei form con validazione dei dati
 
 In pratica, gestire l'invio dei form non si riduce a ricevere i valori inseriti dall'utente. In molti casi il controller dell'applicazione deve:
 
  1. Controllare che i dati siano conformi a un insieme di regole predefinite (campi richiesti, formato delle email, ecc.)
- 2. Opzionalmente trasformare alcuni dati di input per renderli comprensibili (togliere gli spazi bianchi, conertire le date in formato PHP, ecc.)
+ 2. Opzionalmente trasformare alcuni dati di input per renderli comprensibili (togliere gli spazi bianchi, convertire le date in formato PHP, ecc.)
  3. Se i dati non sono validi, mostrare nuovamente il form, con messaggi di errore dove necessario
- 4. Se i dati sono corretti, fare quanto serve con essi, quindi fare un redirect a un'altra azione.
+ 4. Se i dati sono corretti, fare quanto serve con essi, quindi rinviare a un'altra azione.
 
-Symfony fornisce un modo automatico di validare i dati inseriti confrontandoli con un insieme di regole predefinite. Prima definisce un insieme di validatori per ogni campo. Quindi, quando il form è inviato, collega l'oggetto form con i valori inseriti dall'utente (ad esempio, richiama i valori inseriti e li inserisce nel form). Infine, chiede al form di controllare che i dati siano validi. L'esempio che segue mostra come verificare che il valore recuperato dal widget 'email' sia in effetti un indirizzo email, e che il 'messaggio' abbia una dimensione minima di 4 caratteri:
+Symfony fornisce un modo automatico di validare i dati inseriti confrontandoli con un insieme di regole predefinite. Prima definisce un insieme di validatori per ogni campo. Quindi, quando il form è inviato, collega l'oggetto form con i valori inseriti dall'utente (ad esempio, richiama i valori inseriti e li inserisce nel form). Infine, chiede al form di controllare che i dati siano validi. L'esempio che segue mostra come verificare che il valore recuperato dal widget `email` sia in effetti un indirizzo email, e che `message` abbia una dimensione minima di 4 caratteri:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     public function executeContact($request)
     {
       // Define the form
@@ -568,7 +569,7 @@ Symfony fornisce un modo automatico di validare i dati inseriti confrontandoli c
         'message' => new sfValidatorString(array('min_length' => 4))
       ));
 
-      // Trattamento della richiesta
+      // Gestione della richiesta
       if ($request->isMethod('post'))
       {
         $this->form->bind(/* user submitted data */);
@@ -577,33 +578,33 @@ Symfony fornisce un modo automatico di validare i dati inseriti confrontandoli c
           // Gestisce l'invio del form
           // ...
 
-          $this->redirect('foo/bar');
+          $this->redirect('pippo/bar');
         }
       }
     }
 
-'setValidators()' usa una sintassi simile al metodo 'setWidgets()'. 'sfValidatorEmail' e 'sfValidatorString' sono due delle numerose classi di validazione di symfony, elencate più avanti in questo capitolo. Naturalmente, 'sfForm' fornisce anche un metodo 'setValidator()' per aggiungere dei validatori uno per uno.
+`setValidators()` usa una sintassi simile al metodo `setWidgets()`. `sfValidatorEmail` e `sfValidatorString` sono due delle numerose classi di validazione di symfony, elencate più avanti in questo capitolo. Naturalmente, `sfForm` fornisce anche un metodo `setValidator()` per aggiungere dei validatori uno per uno.
 
 Per inserire i dati della richiesta nel form e collegarli, si usa il metodo 'sfForm::bind()'. Un form deve essere collegato con qualche dato per controllare la loro validità.
 
-'isValid()' controlla che tutti i validatori registrati siano superati. In questo caso, 'isValid()' restituisce 'true', e l'azione può procedere con la submission del form. Se il form non è valido, l'azione termina con il default 'sfView::SUCCESS' e mostra nuovamente il fom. Il form però non viene mostrato con i valori di default come la prima volta: gli input del form sono riempiti con i dati inseriti in precedenza dall'utente, e dei messaggi di errori appaiono dove i validatori non sono stati superati.
+'isValid()' controlla che tutti i validatori registrati siano superati. In questo caso, `isValid()` restituisce `true`, e l'azione può procedere con la submission del form. Se il form non è valido, l'azione termina con il default `sfView::SUCCESS` e mostra nuovamente il fom. Il form però non viene mostrato con i valori di default come la prima volta: gli input del form sono riempiti con i dati inseriti in precedenza dall'utente, e dei messaggi di errori appaiono dove i validatori non sono stati superati.
 
-![Invalid form](http://www.symfony-project.org/images/forms_book/en/02_01.png)
+![Form non valido](http://www.symfony-project.org/images/forms_book/en/02_01.png)
 
->**TIP**: Il processo di validazione non si ferma quando il form incontra un campo non valido. 'isValid()' processa tutti i dati del form e controlla tutti i campi alla ricerca di errori, per evitare di mostrare nuovi messaggi di errori quando l'errore corregge i suoi errori e invia il form nuovamente.
+>**TIP**: Il processo di validazione non si ferma quando il form incontra un campo non valido. `isValid()` processa tutti i dati del form e controlla tutti i campi alla ricerca di errori, per evitare di mostrare nuovi messaggi di errori quando l'errore corregge i suoi errori e invia il form nuovamente.
 
 ### Utilizzo di dati form puliti
 
-Nell'elenco precedente, non abbiamo definito i dati della richiesta ricevuti dal form durante il processo di binding. Il problema è che la richiesta non contiene solo i dati del form. Essa contiene anche headers, cookies, parametri passati come argomenti GET, e tutto questo potrebbe inquinare il processo di binding. Una buona pratica è di passare solo i dati del form al metodo 'bind()'.
+Nell'elenco precedente, non abbiamo definito i dati della richiesta ricevuti dal form durante il processo di bind. Il problema è che la richiesta non contiene solo i dati del form. Essa contiene anche header, cookie, parametri passati come argomenti `GET`, e tutto questo potrebbe inquinare il processo di bind. Una buona pratica è di passare solo i dati del form al metodo `bind()`.
 
-Fortunatamente, symfony offre un modo per denominare tutti gli input del form usando un array. Si può definire il formato dell'attributo nome con il metodo 'serNameFormat()' nell'azione quando si definisce il form, come segue:
+Fortunatamente, symfony offre un modo per denominare tutti gli input del form usando un array. Si può definire il formato dell'attributo nome con il metodo `setNameFormat()` nell'azione quando si definisce il form, come segue:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form->setNameFormat('contact[%s]');
 
-In questo modo tutti gli input vengono generati con un nome del tipo 'form[WIDGET_NAME]' anziché semplicemente 'WIDGET_NAME':
+In questo modo tutti gli input vengono generati con un nome del tipo `form[NOME_WIDGET]` anziché semplicemente `NOME_WIDGET`:
 
     [php]
     <label for="contact_name">Name</label>
@@ -622,11 +623,11 @@ In questo modo tutti gli input vengono generati con un nome del tipo 'form[WIDGE
     <label for="contact_message">Message</label>
     <textarea rows="4" cols="30" name="contact[message]" id="contact_message"></textarea>
 
-L'azione può adesso recuperare il parametro 'contact' della richiesta in una singola variabile:
+L'azione può adesso recuperare il parametro `contact` della richiesta in una singola variabile:
 
     [php]
-    // in modules/foo/actions/actions.class.php
-    // Deal with the request
+    // in modules/pippo/actions/actions.class.php
+    // Gestione della richiesta
     if ($request->isMethod('post'))
     {
       $this->form->bind($request->getParameter('contact'));
@@ -641,16 +642,16 @@ L'azione può adesso recuperare il parametro 'contact' della richiesta in una si
 
         // Fa qualcosa...
         // ...
-        $this->redirect('foo/bar');
+        $this->redirect('pippo/bar');
       }
     }
 
-Quando il metodo 'bind()' riceve un array di parametri, symfony automaticamente evita di inserire dei campi addizionali dal lato client. Questa caratteristica di sicurezza fa sì che la validazione del form fallisca se l'array dei parametri 'contact' contiene un campo che non appare nella definizione originale del form.
+Quando il metodo `bind()` riceve un array di parametri, symfony automaticamente evita di inserire dei campi addizionali dal lato client. Questa caratteristica di sicurezza fa sì che la validazione del form fallisca se l'array dei parametri `contact` contiene un campo che non appare nella definizione originale del form.
 
-Si noterà un'ulteriore differenza nel codice dell'azione appena vista rispetto a quello visto precedentemente. L'azione usa l'array di valori passato dall'oggetto form ('$form->getValues()') piuttosto di quelli provenienti dalla richiesta. Questo perché i validatori hanno la capacità di filtrare l'input e pulirlo, cosicché è sempre meglio fare affidamento sui dati recuperati dall'oggetto form (attraverso 'getValues()' o 'getValue()' piuttosto che su quelli provenienti direttamente dalla richiesta. Per campi compositi (come quelli dei widget date), i dati restituiti da 'getValues()' sono già ricomposti nei nomi originali:
+Si noterà un'ulteriore differenza nel codice dell'azione appena vista rispetto a quello visto precedentemente. L'azione usa l'array di valori passato dall'oggetto form (`$form->getValues()`) piuttosto di quelli provenienti dalla richiesta. Questo perché i validatori hanno la capacità di filtrare l'input e pulirlo, cosicché è sempre meglio fare affidamento sui dati recuperati dall'oggetto form (attraverso `getValues()` o `getValue()` piuttosto che su quelli provenienti direttamente dalla richiesta. Per campi compositi (come quelli dei widget data), i dati restituiti da `getValues()` sono già ricomposti nei nomi originali:
 
     [php]
-    // I controlli form di un widget 'date'...
+    // I controlli form di un widget data...
     <label for="contact_dob">Date of birth</label>
     <select id="contact_dob_month" name="contact[dob][month]">...</select> /
     <select id="contact_dob_day" name="contact[dob][day]">...</select> /
@@ -665,11 +666,11 @@ Si noterà un'ulteriore differenza nel codice dell'azione appena vista rispetto
     $contact = $this->form->getValues();
     $dateOfBirth = $contact['dob'];
 
-Dunque è meglio prendere l'abitudine di usare sempre una sintassi di tipo array per i propri campi form (usando 'setNameFormat()') e di usare sempre l'output pulito del form (usando 'getValues()').
+Dunque è meglio prendere l'abitudine di usare sempre una sintassi di tipo array per i propri campi form (usando `setNameFormat()`) e di usare sempre l'output pulito del form (usando `getValues()`).
 
 ### Personalizzare la visualizzazione dei messaggi di errore
 
-Da dove vengono i messaggi di errore mostrati nello screenshot precedente? Ebbene, un widget è fatto di quattro componenti, e il messaggio di errore è uno di questi. Infatti il formatter (table) di default rende la riga di un campo come segue:
+Da dove vengono i messaggi di errore mostrati nella schermata precedente? Ebbene, un widget è fatto di quattro componenti e il messaggio di errore è uno di questi. Infatti il formatter predefinito (table) rende la riga di un campo come segue:
 
     [php]
     <?php if ($field->hasError()): ?>
@@ -698,7 +699,7 @@ Usando uno qualsiasi dei metodi visti sopra, si può personalizzare dove e come
 
 ### Personalizzare i validatori
 
-In un form tutti i campi devono avere un validatore e per default tutti i campi sono richiesti. Se si deve settare un campo come opzionale, bisogna passare l'opzione 'required' al validatore settandola su 'false'. Ad esempio, la lista che segue mostra come rendere il campo 'name' richiesto e il campo 'email' opzionale:
+In un form tutti i campi devono avere un validatore e per default tutti i campi sono richiesti. Se si deve impostare un campo come opzionale, bisogna passare l'opzione `required` al validatore impostandola su 'false'. Ad esempio, la lista che segue mostra come rendere il campo `name` richiesto e il campo 'email' opzionale:
 
     [php]
     $this->form->setValidators(array(
@@ -708,7 +709,7 @@ In un form tutti i campi devono avere un validatore e per default tutti i campi
       'message' => new sfValidatorString(array('min_length' => 4))
     ));
 
-Si può applicare più di un validatore a un singolo campo. Ad esempio, si può voler controllare che il campo 'email' soddisfi sia il validatore 'sfValidatorEmail' che quello 'sfValidatorString' con una dimensione minima di 4 caratteri. In tal caso, si usa il validatore 'sfValidatorAnd' per combinare i due validatori, passandogli come argomenti i due validatori 'sfValidatorEmail' e 'sfValidatorString':
+Si può applicare più di un validatore a un singolo campo. Ad esempio, si può voler controllare che il campo `email` soddisfi sia il validatore `sfValidatorEmail` che quello `sfValidatorString` con una dimensione minima di 4 caratteri. In tal caso, si usa il validatore `sfValidatorAnd` per combinare i due validatori, passandogli come argomenti i due validatori `sfValidatorEmail` e `sfValidatorString`:
 
     [php]
     $this->form->setValidators(array(
@@ -721,12 +722,12 @@ Si può applicare più di un validatore a un singolo campo. Ad esempio, si può
       'message' => new sfValidatorString(array('min_length' => 4))
     ));
 
-Se entrambi i validatori sono validi, il campo 'email' viene dichiarato valido. Similmente, si può usare il validatore 'sfValidatorOr' per combinare più validatori. È sufficiente che uno di essi sia valido perché il campo sia dichiarato valido.
+Se entrambi i validatori sono validi, il campo 'email' viene dichiarato valido. Similmente, si può usare il validatore `sfValidatorOr` per combinare più validatori. È sufficiente che uno di essi sia valido perché il campo sia dichiarato valido.
 
-Ogni validatore invalido risulta in un messaggio di errore nel campo. Questi messaggi di errore sono in inglese, ma è possibile usare gli helper di internazionalizzazione di symfony. Se un progetto usa altri linguaggi, è possibile tradurre facilmente i messaggi di errore con un dizionario i18n. Alternativamente, ogni validatore prevede un terzo argomento per personalizzare i suoi messaggi di errore. Ogni validatore ha almeno due messaggi di errore: il messaggio 'required' e quello 'invalid'. Alcuni validatori possono mostrare messaggi di errore per uno scopo differente, e supportano sempre l'overriding dei messaggi di errore attraverso il loro terzo argomento:
+Ogni validatore invalido risulta in un messaggio di errore nel campo. Questi messaggi di errore sono in inglese, ma è possibile usare gli helper di internazionalizzazione di symfony. Se un progetto usa altri linguaggi, è possibile tradurre facilmente i messaggi di errore con un dizionario i18n. Alternativamente, ogni validatore prevede un terzo parametro per personalizzare i suoi messaggi di errore. Ogni validatore ha almeno due messaggi di errore: il messaggio `required` e quello `invalid`. Alcuni validatori possono mostrare messaggi di errore per uno scopo differente, e supportano sempre l'override dei messaggi di errore attraverso il loro terzo parametro:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     $this->form->setValidators(array(
       'name'    => new sfValidatorString(),
       'email'   => new sfValidatorEmail(array(), array(
@@ -744,14 +745,14 @@ Naturalmente, questi messaggi personalizzati vengono resi nei template attravers
 
 ### Applicare un validatore a più campi
 
-La sintassi usata sopra per definire i validatori in un form non consente di verificare che due campi siamo validi *contemporaneamente*. Ad esempio, in un form di registrazione, ci sono spesso due campi 'password' che devono corrispondere, altrimenti la registrazione viene rifiutata. Ogni campo password non è valido per sè stesso, ma solo se associato con l'altro campo. 
+La sintassi usata sopra per definire i validatori in un form non consente di verificare che due campi siamo validi *contemporaneamente*. Ad esempio, in un form di registrazione, ci sono spesso due campi `password` che devono corrispondere, altrimenti la registrazione viene rifiutata. Ogni campo password non è valido per sè stesso, ma solo se associato con l'altro campo. 
 
-Questo spiega perché sia possibile impostare un validatore 'multiplo' attraverso 'setPostValidator()' per settare i validatori che lavorano su diversi valori. Il post-validator è eseguito dopo tutti gli altri validatori e riceve un array di valori ripuliti. Se si necessita di validare i dati grezzi provenienti dagli input del form, si può invece usare il metodo 'setPreValidator()'.
+Questo spiega perché sia possibile impostare un validatore 'multiplo' attraverso `setPostValidator()` per impostare i validatori che lavorano su diversi valori. Il post-validatore è eseguito dopo tutti gli altri validatori e riceve un array di valori ripuliti. Se si necessita di validare i dati grezzi provenienti dagli input del form, si può invece usare il metodo `setPreValidator()`.
 
 Una tipica definizione di un form di registrazione potrebbe apparire come segue:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form = new sfForm();
     $this->form->setWidgets(array(
@@ -766,15 +767,15 @@ Una tipica definizione di un form di registrazione potrebbe apparire come segue:
     ));
     $this->form->setPostValidators(new sfValidatorSchemaCompare('password1', '==', 'password2'));
 
-Il validatore 'sfValidatorSchemaCompare' è uno speciale validatore multiplo che riceve tutti i valori ripuliti e può prendere due di essi per una comparazione. Naturalmente è possibile definire più di un post-validator usando i validatori 'sfValidatorAnd' e 'sfValidatorOr'.
+Il validatore `sfValidatorSchemaCompare` è uno speciale validatore multiplo che riceve tutti i valori ripuliti e può prendere due di essi per una comparazione. Naturalmente è possibile definire più di un post-validatore usando i validatori `sfValidatorAnd` e `sfValidatorOr`.
 
 Validatori
 ----------
 
-Symfony un gran numero di validatori. Si ricordi che ogni validatore accetta un array di opzioni e un array di errori come argomenti, dei quali è necessario personalizzare almeno i messaggi di errore 'required' e 'invalid'.
+Symfony un gran numero di validatori. Si ricordi che ogni validatore accetta un array di opzioni e un array di errori come argomenti, dei quali è necessario personalizzare almeno i messaggi di errore `required` e `invalid`.
 
     [php]
-    // validatore String
+    // validatore stringa
     $form->setValidator('message', new sfValidatorString(array(
       'min_length' => 4,
       'max_length' => 50,
@@ -784,7 +785,7 @@ Symfony un gran numero di validatori. Si ricordi che ogni validatore accetta un
       'max_length' => 'Inserire un messaggio più sintetico',
     )));
     
-    // validatore Number
+    // validatore numero
     $form->setValidator('age', new sfValidatorNumber(array( // usare 'sfValidatorInteger' se si desiderano solo valori interi
       'min'  => 18,
       'max'  => 99.99,
@@ -794,55 +795,55 @@ Symfony un gran numero di validatori. Si ricordi che ogni validatore accetta un
       'max' => 'Ti stai prendendo gioco di me? Le persone sopra i 100 anni non usano Internet',
     )));
     
-    // validatore Email
+    // validatore email
     $form->setValidator('email', new sfValidatorEmail());
     
     // validatore URL
     $form->setValidator('website', new sfValidatorUrl());
     
-    // validatore di Espressioni Regolari
+    // validatore di espressioni regolari
     $form->setValidator('IP', new sfValidatorRegex(array(
       'pattern' => '^[0-9]{3}\.[0-9]{3}\.[0-9]{2}\.[0-9]{3}$'
     )));
 
-Sebbene alcuni controlli form (come le liste drop-down, le checkboxes, i gruppi di radio-button) restringano le scelte possibili, un utente malevolo può sempre tentare di intaccare i form manipolando la pagina con Firebug o invando un'interrogazione con un linguaggio di scripting. Di conseguenza si dovrebbero validare anche i campi che accettano un array limitato di valori:
+Sebbene alcuni controlli form (come le liste drop-down, i checkbox, i gruppi di radio-button) restringano le scelte possibili, un utente malevolo può sempre tentare di intaccare i form manipolando la pagina con Firebug o inviando un'interrogazione con un linguaggio di scripting. Di conseguenza si dovrebbero validare anche i campi che accettano un array limitato di valori:
 
     [php]
-    // validatore Boolean
+    // validatore booleano
     $form->setValidator('has_signed_terms_of_service', new sfValidatorBoolean());
     
-    // validatore Choice (per restringere i valori a una lista)
+    // validatore scelta (per restringere i valori a una lista)
     $form->setValidator('subject', new sfValidatorChoice(array(
       'choices' => array('Subject A', 'Subject B', 'Subject C')
     )));
     
-    // validatore Multiple-Choice
+    // validatore scelta multipla
     $form->setValidator('languages', new sfValidatorChoice(array(
       'multiple' => true,
       'choices' => array('en' => 'English', 'fr' => 'French', 'other')
     )));
 
-Esistono dei validatori per scelte I18n delle liste di nazioni (`sfValidatorI18nChoiceCountry`) e di lingue `sfValidatorI18nChoiceLanguage`). Questi validatori accettano una lista ristretta di nazioni e linguaggi se si desidera limitare le opzioni possibili.
+Esistono dei validatori per scelte I18n delle liste di paesi (`sfValidatorI18nChoiceCountry`) e di lingue `sfValidatorI18nChoiceLanguage`). Questi validatori accettano una lista ristretta di paesi e lingue, se si desidera limitare le opzioni possibili.
 
-Il validatore 'sfValidatorChoice' è usato spesso per validare un widget `sfWidgetFormChoice`. E dato che è possibile usare il widget `sfWidgetFormChoice` per colonne di tipo foreign key, symfony fornisce anche un validatore per controllare che il valore della foreign key esista nella tabella collegata:
+Il validatore `sfValidatorChoice` è usato spesso per validare un widget `sfWidgetFormChoice`. Dato che è possibile usare il widget `sfWidgetFormChoice` per chiavi esterne, symfony fornisce anche un validatore per controllare che il valore della chiave esista nella tabella collegata:
 
     [php]
-    // Propel choice validator
+    // Validatore Propel
     $form->setValidator('section_id', new sfValidatorPropelChoice(array(
       'model'  => 'Section',
       'column' => 'name'
     )));
     
-    // Doctrine choice validator
+    // Validatore Doctrine
     $form->setValidator('section_id', new sfValidatorDoctrineChoice(array(
       'model'  => 'Section',
       'column' => 'name'
     )));
 
-Un altro utile validatore legato al Modello è `sfValidatorPropelUnique`, che controlla che un nuovo valore inserito tramite un form non sia in conflitto con un valore esistente in una colonna del database con indice 'unique'. Ad esempio, due utenti non possono avere la stessa 'login', così editango un oggetto 'User' con un form, bisogna aggiungere un validatore `sfValidatorPropelUnique` su questa colonna:
+Un altro utile validatore legato al Modello è `sfValidatorPropelUnique`, che controlla che un nuovo valore inserito tramite un form non sia in conflitto con un valore esistente in una colonna del database con indice `unique`. Ad esempio, due utenti non possono avere lo stesso `login`, così modificando un oggetto `User` con un form, bisogna aggiungere un validatore `sfValidatorPropelUnique` su questa colonna:
 
     [php]
-    // Propel unique validator
+    // Validatore Propel unique
     $form->setValidator('nickname', new sfValidatorPropelUnique(array(
       'model'  => 'User', 
       'column' => 'login'
@@ -857,10 +858,10 @@ Un altro utile validatore legato al Modello è `sfValidatorPropelUnique`, che co
 Per rendere i propri form ancora più sicuri ed evitare attacchi [Cross-Site Request Forgery](http://en.wikipedia.org/wiki/Cross-site_request_forgery), si può abilitare la protezione CSRF:
 
     [php]
-    // CSRF protection - settare la chiave segreta a una stringa casuale che nessuno conosca
+    // CSRF protection - impostare la chiave segreta a una stringa casuale che nessuno conosca
     $form->addCSRFProtection('flkd445rvvrGV34G');
 
->**TIP**: È possibile settare la chiave CSRF per l'intero sito nel file 'settings.yml':
+>**TIP**: È possibile impostare la chiave CSRF per l'intero sito nel file 'settings.yml':
 
     [yml]
     # in apps/myapp/config/settings.yml
@@ -879,15 +880,15 @@ I validatori multipli operano sull'intero form, anziché su un singolo input. Se
     $form->setOption('allow_extra_fields', false);
     $form->setOption('filter_extra_fields', true);
 
-Modi alternativi di usare un Form
+Modi alternativi di usare un form
 ---------------------------------
 
 ### Classi Form
 
-Con tutte le opzioni dei widget, i validatori e i parametri dei form, la definizione del form dei contatti scritta nella classe actions appare piuttosto confusa:
+Con tutte le opzioni dei widget, i validatori e i parametri dei form, la definizione del form dei contatti scritta nella classe delle azioni appare piuttosto confusa:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form = new sfForm();
     $this->form->setNameFormat('contact[%s]');
@@ -906,7 +907,7 @@ Con tutte le opzioni dei widget, i validatori e i parametri dei form, la definiz
       'message' => new sfValidatorString(array('min_length' => 4))
     ));
 
-La migliore prassi consiste nel creare una classe form con le stesse proprietà ed istanziarla in tutte le azioni. Ad esempio, ecco come creare una classe per il form dei contatti:
+La migliore prassi consiste nel creare una classe form con le stesse proprietà e istanziarla in tutte le azioni. Ad esempio, ecco come creare una classe per il form dei contatti:
 
     [php]
     // in lib/form/ContactForm.class.php
@@ -939,29 +940,29 @@ La migliore prassi consiste nel creare una classe form con le stesse proprietà
 Ora definire un oggetto per il form dei contatti nell'azione è molto semplice:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form = new ContactForm();
 
-### Alterare un oggetto Form
+### Alterare un oggetto form
 
-Quando si usa la definizione di una classe form, il form è definito al di fuori dell'azione. Questo rende l'assegnamento dinamico dei valori di default abbastanza difficoltoso. Ecco perché l'oggetto form riceve un array di valori di default come primo argomento:
+Quando si usa la definizione di una classe form, il form è definito al di fuori dell'azione. Questo rende l'assegnamento dinamico dei valori predefiniti abbastanza difficoltoso. Ecco perché l'oggetto form riceve un array di valori predefiniti come primo parametro:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form = new ContactForm(array('email' => 'me@example.com'));
 
-È anche possibile sovrascrivere i widget esistenti o le impostazioni dei validatori richiamando 'setWidget()' o 'setValidator()' su un nome di campo esistente.
+È anche possibile sovrascrivere i widget esistenti o le impostazioni dei validatori richiamando `setWidget()` o `setValidator()` su un nome di campo esistente.
 
 Del resto i widget e i validatori sono oggetti in symfony, e offrono un'API molto pulita per modificare le loro proprietà:
 
     [php]
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     // Definizione del form
     $this->form = new ContactForm();
 
-    // Permettere la selezione di linguaggi multipli
+    // Permettere la selezione più lingue
     $form->getWidget('language')->setOption('multiple', true);
     // Aggiungere un widget 'genere'
     $form->setWidget('genere', new sfWidgetFormChoice(array('expanded' => true, 'choices' => array('m' => 'Male', 'f' => 'Female')), array('class' => 'gender_list')));
@@ -976,10 +977,10 @@ Del resto i widget e i validatori sono oggetti in symfony, e offrono un'API molt
     // Rendere il campo 'name' opzionale
     $form->getValidator('name')->setOption('required', false);
 
-Classi Widget e Validator personalizzate
+Classi widget e validator personalizzate
 ----------------------------------------
 
-Un widget personalizzato è semplicemente una classe che estende 'sfWidgetForm', e fornisce dei metodi 'configure()' e 'render()'. Si scorra il codice delle classi widget esistenti per una comprensione approfondita del sistema dei widget. Il listato che segue mostra il codice del widget 'sfWidgetFormInput' per illustrare la struttura del widget:
+Un widget personalizzato è semplicemente una classe che estende `sfWidgetForm`, e fornisce dei metodi `configure()` e `render()`. Si scorra il codice delle classi widget esistenti per una comprensione approfondita del sistema dei widget. Il listato che segue mostra il codice del widget `sfWidgetFormInput` per illustrare la struttura del widget:
 
     [php]
     class sfWidgetFormInputText extends sfWidgetForm
@@ -1019,7 +1020,7 @@ Un widget personalizzato è semplicemente una classe che estende 'sfWidgetForm',
       }
     }
 
-Una classe validator estende 'sfValidatorBase' e fornisce dei metodi 'configure()' e 'doClean()'. Perché 'doClean()' e non 'validate()'? Perché i validatori fanno due cose: essi controllano che l'input soddisfi un insieme di regole, e opzionalmente puliscono l'input (ad esempio forzando il tipo, eseguendo un trimming, convertendo date da stringhe a timestamp, ecc.). Così il metodo 'doClean()' deve restituire l'input pulito, o sollevare un'eccezione 'sfValidatorError' se l'input non soddisfa una qualsiasi delle regole del validatore. Di seguito viene mostrato questo concetto, con il codice del validatore 'sfValidatorInteger'.
+Una classe validator estende `sfValidatorBase` e fornisce dei metodi `configure()` e `doClean()`. Perché `doClean()` e non `validate()`? Perché i validatori fanno due cose: essi controllano che l'input soddisfi un insieme di regole, e opzionalmente puliscono l'input (ad esempio forzando il tipo, eseguendo un trim, convertendo date da stringhe a timestamp, ecc.). Così il metodo `doClean()` deve restituire l'input pulito, o sollevare un'eccezione `sfValidatorError` se l'input non soddisfa una qualsiasi delle regole del validatore. Di seguito viene mostrato questo concetto, con il codice del validatore `sfValidatorInteger`.
 
     [php]
     class sfValidatorInteger extends sfValidatorBase
@@ -1077,9 +1078,9 @@ Una classe validator estende 'sfValidatorBase' e fornisce dei metodi 'configure(
 Si veda la documentazione dell'API di symfony per i nomi e la sintassi delle classi widget e validator.
 
 >**SIDEBAR**
->Usare le opzioni per passare perametri alla classe form
+>Usare le opzioni per passare parametri alla classe form
 >
->Un problema comune coi form è di usare i parametri dell'applicazione, come ad esempio la culture dell'utente. La via più veloce ma peggiore è di richiamare l'instanza dell'utente attraverso l'instanza sfContext, usando il metodo 'sfContext::getInstance()->getUser()'. Tuttavia questa soluzione lega fortemente il form al contesto, rendendo il testing e la riusabilità più difficoltosi. Per evitare questo problema, si può usare semplicemente l'opzione di passare il valore 'culture' al form:
+>Un problema comune coi form è di usare i parametri dell'applicazione, come ad esempio la cultura dell'utente. La via più veloce, ma peggiore, è richiamare l'instanza dell'utente attraverso l'instanza `sfContext`, usando il metodo `sfContext::getInstance()->getUser()`. Tuttavia questa soluzione lega fortemente il form al context, rendendo i test e la riusabilità più difficoltosi. Per evitare questo problema, si può usare semplicemente l'opzione di passare il valore `culture` al form:
 
 >
 >     // da un'azione
@@ -1105,13 +1106,13 @@ Si veda la documentazione dell'API di symfony per i nomi e la sintassi delle cla
 Form basati su un Modello
 -------------------------
 
-I form sono il modo principale per modificare i record di un database nelle applicazioni web. E molti form nelle applicazioni symfony permettono di editare un oggetto Model. Del resto le informazioni necessarie per costruire un form per editare un modello esistono già: esse sono nello schema. Così symfony fornisce un form generator per gli oggetti del modello, che rende la creazione di form un gioco da ragazzi.
+I form sono il modo principale per modificare i record di un database nelle applicazioni web. Molti form nelle applicazioni symfony permettono di editare un oggetto del Modello. Del resto le informazioni necessarie per costruire un form per editare un modello esistono già: sono nello schema. Così symfony fornisce un generatore di form per gli oggetti del Modello, che rende la creazione di form un gioco da ragazzi.
 
 >**Note**: Caratteristiche simili a quelle descritte nel seguito esistono per Doctrine.
 
-### Generare i Form dal Modello
+### Generare i form dal Modello
 
-Symfony può dedurre i tipi di widget e i validatori da usare per un form, basandosi sullo schema. Si prenda as esempio lo schema seguente, con l'ORM Propel:
+Symfony può dedurre i tipi di widget e i validatori da usare per un form, basandosi sullo schema. Si prenda ad esempio lo schema seguente, con l'ORM Propel:
 
     [yml]
     // config/schema.yml
@@ -1132,7 +1133,7 @@ Symfony può dedurre i tipi di widget e i validatori da usare per un form, basan
         email:        { type: varchar(255), required: true, index: unique }
         active:       boolean
 
-Un form per editare un oggetto 'Article' dovrebbe usare un widget nascosto per l'id, un widget testo per 'title', un validatore stringa per 'title', ecc. Symfony genera il form automaticamente, semplicemente richiamando il task 'propel:build-forms':
+Un form per editare un oggetto `Article` dovrebbe usare un widget nascosto per l'id, un widget testo per `title`, un validatore stringa per `title`, ecc. Symfony genera il form automaticamente, semplicemente richiamando il task `propel:build-forms`:
 
     // propel
     $ php symfony propel:build-forms
@@ -1140,9 +1141,9 @@ Un form per editare un oggetto 'Article' dovrebbe usare un widget nascosto per l
     // doctrine
     $ php symfony doctrine:build-forms
 
-Per ogni tabella nel modello, questo comando crea due file nella cartella 'lib/form/': una classe 'BaseXXXForm', sovrascritta ogni volta che si richiama il task 'propel:build-form', a una classe 'XXXForm' vuota, che estende la precedente. E' lo stesso sistema usato dalla generazione delle classi modello di Propel.
+Per ogni tabella nel modello, questo comando crea due file nella cartella `lib/form/`: una classe `BaseXXXForm`, sovrascritta ogni volta che si richiama il task `propel:build-form`, a una classe `XXXForm` vuota, che estende la precedente. È lo stesso sistema usato dalla generazione delle classi modello di Propel.
 
-Il file 'lib/form/base/BaseArticleForm.class.php' generato contiene la traduzione in widget e validatori delle colonne definite per la tabella 'article' in 'schema.yml':
+Il file `lib/form/base/BaseArticleForm.class.php` generato contiene la traduzione in widget e validatori delle colonne definite per la tabella `article` in `schema.yml`:
 
     [php]
     class BaseArticleForm extends BaseFormPropel
@@ -1180,13 +1181,13 @@ Il file 'lib/form/base/BaseArticleForm.class.php' generato contiene la traduzion
       }
     }
 
-Si noti che, anche se la colonna 'id' è un Integer, symfony controlla che l'id presentato esista nella tabella usando un validatore 'sfValidatorPropelChoice'. Il generatore di form setta sempre le regole di validazione più restrittive, per assicurare i dati più puliti al database.
+Si noti che, anche se la colonna `id` è un intero, symfony controlla che l'id presentato esista nella tabella usando un validatore `sfValidatorPropelChoice`. Il generatore di form imposta sempre le regole di validazione più restrittive, per assicurare i dati più puliti al database.
 
-### Usare i Model Form
+### Usare i form del Modello
 
-È possibile personalizzare le classi dei form generati per l'intero progetto aggiungendo del codice al metodo 'ArticleForm::configure()' inizialmente vuoto.
+È possibile personalizzare le classi dei form generati per l'intero progetto aggiungendo del codice al metodo `ArticleForm::configure()`, inizialmente vuoto.
 
-Segue un esempio di manipolazione del model form in un'azione. In questo form, il validatore 'slug' è modificato per rendere il campo opzionale, e il widget 'author_id' è personalizzato per mostrare solo un sottoinsieme degli autori: solo quelli attivi.
+Segue un esempio di manipolazione del model form in un'azione. In questo form, il validatore `slug` è modificato per rendere il campo opzionale, e il widget `author_id` è personalizzato per mostrare solo un sottoinsieme degli autori: solo quelli attivi.
 
     [php]
     // in lib/form/ArticleForm.class.php
@@ -1196,7 +1197,7 @@ Segue un esempio di manipolazione del model form in un'azione. In questo form, i
       $this->getValidator('slug')->setOption('required', false);
     }
 
-    // in modules/foo/actions/actions.class.php
+    // in modules/pippo/actions/actions.class.php
     public function executeEditArticle($request)
     {
       $c = new Criteria();
@@ -1219,15 +1220,15 @@ Segue un esempio di manipolazione del model form in un'azione. In questo form, i
       }
     }
 
-Invece di settare dei valori di default attraverso un array associativo, i Model form usano un oggetto Model per inizializzare i valori del widget. Per mostrare un form vuoto, è sufficiente passare un nuovo oggetto Model.
+Invece di impostare dei valori predefiniti attraverso un array associativo, i form del Modello usano un oggetto del Modello per inizializzare i valori del widget. Per mostrare un form vuoto, è sufficiente passare un nuovo oggetto del Modello.
 
-La gestione dell'invio dei form è grandemente semplificata dal fatto che l'oggetto form contiene un oggetto Model incapsulato. Richiamando '$this->form->save()' in un form valido l'oggetto 'Article' incapsulato viene aggiornato con i valori puliti e il suo metodo 'save()' viene innescato, purché l'oggetto relativo esista.
+La gestione dell'invio dei form è grandemente semplificata dal fatto che l'oggetto form contiene un oggetto del Modello incapsulato. Richiamando `$this->form->save()` in un form valido, l'oggetto `Article` incapsulato viene aggiornato con i valori puliti e il suo metodo `save()` viene innescato, purché l'oggetto relativo esista.
 
->**TIP**: Il codice per l'azione richiesto per trattare con un form è praticamente sempre lo stesso, ma questa non è una ragione per copiarlo da un modulo all'altro. Symfony fornisce un generatore di moduli che crea tutto il codice per le azioni e i template per manipolare un oggetto Model attraverso i form di symfony.
+>**TIP**: Il codice per l'azione richiesto per trattare con un form è praticamente sempre lo stesso, ma questa non è una ragione per copiarlo da un modulo all'altro. Symfony fornisce un generatore di moduli che crea tutto il codice per le azioni e i template per manipolare un oggetto del Modello attraverso i form di symfony.
 
 Conclusione
 -----------
 
-Il componente form di symfony è in sè già un intero framework. Esso facilita la visualizzazione dei form nella View attraverso widgets, facilita la validazione e la manipolazione dei form nel Controller attraverso i validatori, a facilita la modifica degli oggetti Model attraverso i Model form. Nonostante sia progettato con una chiara separazione MVC, il sub-framework dei form è sempre facile da usare. Nella maggior parte dei casi, la generazione del codice riduce la personalizzazione dei propri form a poche linee di codice.
+Il componente form di symfony è in sé già un intero framework. Esso facilita la visualizzazione dei form nella Vista attraverso i widget, facilita la validazione e la manipolazione dei form nel Controller attraverso i validatori, a facilita la modifica degli oggetti del Modello attraverso i form del Modello. Nonostante sia progettato con una chiara separazione MVC, il sub-framework dei form è sempre facile da usare. Nella maggior parte dei casi, la generazione del codice riduce la personalizzazione dei propri form a poche linee di codice.
 
-C'è molto di più nelle classi form di symfony rispetto a quanto questo capitolo ha esposto. Infatti esiste un [intero libro](http://www.symfony-project.org/book/forms/1_4/en/) che descrive le loro caratteristiche con l'uso di esempi. E se il form framework non offre i widget o i validatori di cui si ha bisogno, esso è progettato in modo da essere estensibile con la scrittura di una singola classe per fare esattamente quello che serve.
+C'è molto di più nelle classi form di symfony rispetto a quanto questo capitolo ha esposto. Infatti esiste un [intero libro](http://www.symfony-project.org/book/forms/1_4/it/) che descrive le loro caratteristiche con l'uso di esempi. E se il form framework non offre i widget o i validatori di cui si ha bisogno, esso è progettato in modo da essere estensibile con la scrittura di una singola classe per fare esattamente quello che serve.
diff --git a/gentle-introduction/it/16-Application-Management-Tools.markdown b/gentle-introduction/it/16-Application-Management-Tools.markdown
index d9837d9..4b1d506 100644
--- a/gentle-introduction/it/16-Application-Management-Tools.markdown
+++ b/gentle-introduction/it/16-Application-Management-Tools.markdown
@@ -141,7 +141,7 @@ Non bisogna dimenticare di eliminare periodicamente la cartella `log/` delle app
 
     $ php symfony log:clear
 
-Sia per questioni di prestazioni che di sicurezza, probabilmente si vorrà memorizzare i log di symfony in diversi piccoli file invece di un singolo file di grandi dimensioni. La strategia di memorizzazione ideale per i file di log è quella di eseguire il backup e svuotare il file di log principale regolarmente, ma di tenere solo un numero limitato di backup. È possibile attivare un tale rotazione dei log con un `periodo` di `7` giorni ed uno `storico` (numero di copie di backup) di `10`, come mostrato nel Listato 16-7. Si potrebbe lavorare con un file di log attivo più dieci file di backup contenenti sette giorni di storia per ciascuno. Ogni volta che il prossimo periodo di sette giorni termina, il file di registro corrente va nel backup, e il backup più vecchio viene cancellato.
+Sia per questioni di prestazioni che di sicurezza, probabilmente si vorrà memorizzare i log di symfony in diversi piccoli file invece di un singolo file di grandi dimensioni. La strategia di memorizzazione ideale per i file di log è quella di eseguire il backup e svuotare il file di log principale regolarmente, ma di tenere solo un numero limitato di backup. È possibile attivare un tale rotazione dei log con un `periodo` di `7` giorni e uno `storico` (numero di copie di backup) di `10`, come mostrato nel Listato 16-7. Si potrebbe lavorare con un file di log attivo più dieci file di backup contenenti sette giorni di storia per ciascuno. Ogni volta che il prossimo periodo di sette giorni termina, il file di registro corrente va nel backup, e il backup più vecchio viene cancellato.
 
 Listato 16-7 - Avviare la rotazione dei log
 
@@ -158,10 +158,10 @@ Non importa quanto si sia abili a programmare, perché si fanno sempre degli err
 
 Symfony ha una modalità di debug che facilita lo sviluppo e il debug delle applicazioni. Quando è abilitata, succedono le cose seguenti:
 
-  * La configurazione viene verificata ad ogni richiesta, così la modifica di un qualunque file di configurazione ha un effetto immediato, senza che ci sia la necessità di cancellare la cache della configurazione.
+  * La configurazione viene verificata a ogni richiesta, così la modifica di un qualunque file di configurazione ha un effetto immediato, senza che ci sia la necessità di cancellare la cache della configurazione.
   * I messaggi di errore visualizzano l'intero stack trace in modo chiaro, in modo che si possa trovare velocemente la causa del problema.
   * Sono disponibili più strumenti per il debug (ad esempio i dettagli delle query al database).
-  * E' anche attivata la modalità di debug per Propel/Doctrine, quindi per qualunque errore in una chiamata ad un oggetto Propel/Doctrine verrà mostrata una catena dettagliata con le chiamate dell'architettura Propel/Doctrine.
+  * È anche attivata la modalità di debug per Propel/Doctrine, quindi per qualunque errore in una chiamata a un oggetto Propel/Doctrine verrà mostrata una catena dettagliata con le chiamate dell'architettura Propel/Doctrine.
 
 Al contrario, quando la modalità debug è disattivata, l'elaborazione viene gestita nel modo seguente:
 
@@ -188,7 +188,7 @@ Listato 16-8 - Esempio di front controller con la modalità di debug attivata, i
 
 Quando si verifica un'eccezione nella modalità di debug, symfony mostra un'utile informazione dull'eccezione che contiene tutto quello di cui si ha bisogno per trovare la causa del problema.
 
-I messaggi con le eccezioni sono scritti in modo chiaro e indicano la causa più probabile del problema. Spesso forniscono una possibile soluzione per risolvere il problema e per la maggior parte dei problemi più comuni, la pagina con l'eccezione può contenere un link a una pagina del sito di symfony con maggiori dettagli sull'eccezione. La pagina dell'eccezione mostra dove è avvenuto l'errore nel codice PHP (con evidenziazione colorata della sintassi), insieme allo stack completo delle chiamate di metodoto, come mostrato in Figura 16-1. E' possibile seguire il trace alla prima chiamata che ha causato il problema. Sono anche indicati gli argomenti che sono stati passati ai metodi.
+I messaggi con le eccezioni sono scritti in modo chiaro e indicano la causa più probabile del problema. Spesso forniscono una possibile soluzione per risolvere il problema e per la maggior parte dei problemi più comuni, la pagina con l'eccezione può contenere un link a una pagina del sito di symfony con maggiori dettagli sull'eccezione. La pagina dell'eccezione mostra dove è avvenuto l'errore nel codice PHP (con evidenziazione colorata della sintassi), insieme allo stack completo delle chiamate di metodoto, come mostrato in Figura 16-1. È possibile seguire il trace alla prima chiamata che ha causato il problema. Sono anche indicati gli argomenti che sono stati passati ai metodi.
 
 >**NOTE**
 >Symfony si basa proprio sulle eccezioni PHP per la segnalazione degli errori. Ad esempio, l'errore 404 può essere lanciato da un `sfError404Exception`.
@@ -221,7 +221,7 @@ Listato 16-9 - Esempio di configurazione di Xdebug
     ;xdebug.show_local_vars=1
     ;xdebug.max_nesting_level=100
 
-Bisogna riavviare il web server perchè la modalità Xdebug venga attivata.
+Bisogna riavviare il web server perché la modalità Xdebug venga attivata.
 
 >**CAUTION**
 >Non dimenticarsi di disabilitare la modalità Xdebug nella piattaforma di produzione. Non facendolo, si rallenta di molto l'esecuzione di ogni pagina.
@@ -300,7 +300,7 @@ Figura 16-6 - L'icona con l'orologio mostra il tempo di esecuzione per categoria
 >     // Recupera il risultato (e ferma il cronometro se non è giù stato fermato)
 >     $elapsedTime = $timer->getElapsedTime();
 >
->Il vantaggio di dare un nome ad ogni timer è che si può chiamare più volte per accumulare conteggi. Per esempio, se il cronometro `mioTimer` viene utilizzato in un metodo che viene chiamato due volte ad ogni richiesta, la seconda chiamata al metodo `getTimer('mioTimer')` farà ripartire il cronometro dal punto calcolato quando `addTime()` era stato chiamato l'ultima volta, per cui i tempi si sommano a quelli precedenti. Chiamando `getCalls()` sull'oggetto timer si ottiene il numero di volte in cui è stato lanciato il cronometro e questo dato viene visualizzato anche nella barra web di debug.
+>Il vantaggio di dare un nome a ogni timer è che si può chiamare più volte per accumulare conteggi. Per esempio, se il cronometro `mioTimer` viene utilizzato in un metodo che viene chiamato due volte a ogni richiesta, la seconda chiamata al metodo `getTimer('mioTimer')` farà ripartire il cronometro dal punto calcolato quando `addTime()` era stato chiamato l'ultima volta, per cui i tempi si sommano a quelli precedenti. Chiamando `getCalls()` sull'oggetto timer si ottiene il numero di volte in cui è stato lanciato il cronometro e questo dato viene visualizzato anche nella barra web di debug.
 >
 >     [php]
 >     // Recupera il numero di chiamate a timer
@@ -315,7 +315,7 @@ Figura 16-6 - L'icona con l'orologio mostra il tempo di esecuzione per categoria
 
 ### Debug manuale
 
-E' bello avere l'accesso ai messaggi di debug del framework, ma è ancora meglio essere in grado di accedere ai propri messaggi. Symfony fornisce scorciatoie, accessibili sia dalle azioni che dai modelli, per aiutare a traccaire eventi e/o valori durante l'esecuzione della richiesta.
+È bello avere l'accesso ai messaggi di debug del framework, ma è ancora meglio essere in grado di accedere ai propri messaggi. Symfony fornisce scorciatoie, accessibili sia dalle azioni che dai modelli, per aiutare a traccaire eventi e/o valori durante l'esecuzione della richiesta.
 
 I messaggi di log personalizzati vengono salvati nel file di log di symfony e compaiono nella barra web per il debug. (Il Listato 16-5 fornisce un esempio della sintassi per un messaggio di log personalizzato. Un messaggio personalizzato è un buon modo per controllare il valore di una variabile da un template, ad esempio. Il Listato 16-11 mostra come usare la barra web per il debug per avere il feedback da un template (da una azione invece, si può utilizzare `$this->logMessage()`).
 
@@ -455,7 +455,7 @@ Nel processo di sviluppo delle applicazioni, gli sviluppatori devono spesso affr
 
 ### Sintassi del file per le fixture
 
-Symfony è in grado di leggere file di dati che seguono una sintassi molto semplice chiamata YAML, a condizione che si trovino sotto la cartella `data/fixtures/`. I file con le fixture sono organizzati per classi ed ogni sezione di una classe inizia con il nome della classe come intestazione. Per ciascuna classe, i record etichettati con una stringa univoca sono definiti da una serie di coppie `nomecampo: valore`.
+Symfony è in grado di leggere file di dati che seguono una sintassi molto semplice chiamata YAML, a condizione che si trovino sotto la cartella `data/fixtures/`. I file con le fixture sono organizzati per classi e ogni sezione di una classe inizia con il nome della classe come intestazione. Per ciascuna classe, i record etichettati con una stringa univoca sono definiti da una serie di coppie `nomecampo: valore`.
 Il Listato 16-15 mostra un esempio di un file di dati per popolare il database.
 
 Listato 16-15 - Esempio di un file fixture, in `data/fixtures/import_data.yml`
@@ -499,7 +499,7 @@ Nella chiamata è possibile specificare un'altra cartella per le fixture. In que
 
 ### Utilizzo di tabelle collegate
 
-Si è imparato come aggiungere record ad una singola tabella, ma come si fa ad aggiungere record con chiavi esterne ad un'altra tabella? Dal momento che la chiave primaria non è inclusa nei dati delle fixture, c'è bisogno di un modo alternativo per relazionare dei record con altri.
+Si è imparato come aggiungere record a una singola tabella, ma come si fa ad aggiungere record con chiavi esterne a un'altra tabella? Dal momento che la chiave primaria non è inclusa nei dati delle fixture, c'è bisogno di un modo alternativo per relazionare dei record con altri.
 
 Torniamo all'esempio del Capitolo 8, dove la tabella `blog_article` è collegata alla tabella `blog_comment`, come mostrato in Figura 16-8.
 
@@ -509,7 +509,7 @@ Figura 16-8 - Esempio di un modello relazionale di database
 
 Questo è un esempio di come le etichette date ai record siano effettivamente utili. Per aggiungere un campo `Comment` all'articolo `first_post`, si possono semplicemente aggiungere le righe mostrate nel Listato 16-16 al file di dati `import_data.yml`.
 
-Listing 16-16 - Aggiungere un record ad una tabella collegata, in `data/fixtures/import_data.yml`
+Listing 16-16 - Aggiungere un record a una tabella collegata, in `data/fixtures/import_data.yml`
 
     Comment:
       first_comment:
@@ -517,14 +517,14 @@ Listing 16-16 - Aggiungere un record ad una tabella collegata, in `data/fixtures
         author:       Anonymous
         content:      La tua prosa è troppo prolissa. Scrivere frasi più brevi.
 
-Il task `propel:data-load` riconosce l'etichetta che è stata data precedentemente ad un articolo nel file `import_data.yml` e prende la chiave primaria del corrispondente record di `Article` per impostare il campo `article_id`. Non si vedranno mai gli ID dei record, è sufficiente collegarli alle loro etichette.
+Il task `propel:data-load` riconosce l'etichetta che è stata data precedentemente a un articolo nel file `import_data.yml` e prende la chiave primaria del corrispondente record di `Article` per impostare il campo `article_id`. Non si vedranno mai gli ID dei record, è sufficiente collegarli alle loro etichette.
 		
 L'unico vincolo per i record collegati è che gli oggetti chiamati in una chiave esterna devono essere definiti in precedenza nel file; il che è come si farebbe se si definissero uno per uno. I file di dati vengono analizzati dall'alto verso il basso e l'ordine in cui sono scritti i record è importante.
 
 Questo metodo funziona anche per le relazioni molti a molti, dove due classi sono collegate attraverso una terza classe. Ad esempio, un `Article` può avere molti `Authors` e un `Author` può avere molti `Articles`. Di solito per fare questo si utilizza la classe `ArticleAuthor`, corrispondente a una tabella `article_author` con una colonna `article_id` e una colonna `author_id`.
 Il Listato 16-17 mostra come scrivere un file fixture per definire relazioni molti a molti con questo modello. Notare il nome della tabella in plurale che è stato usato qui. Questo è ciò che fa scattare la voglia di avere una classe intermedia.
 
-Listato 16-17 - Aggiungere un record ad una tabella collegata con una relazione molti a molti, in `data/fixtures/import_data.yml`
+Listato 16-17 - Aggiungere un record a una tabella collegata con una relazione molti a molti, in `data/fixtures/import_data.yml`
 
     Author:
       first_author:
@@ -551,9 +551,9 @@ Symfony offre comandi manuali per sincronizzare due versioni di un sito web. Que
 
 ### L'utilizzo di `rsync` per il trasferimento incrementale di file
 
-L'invio della cartella principale di un progetto tramite FTP va bene per il primo trasferimento, ma quando si ha bisogno di caricare un aggiornamento dell'applicazione, in cui sono cambiati solo alcuni file, l'FTP non è l'ideale. È necessario trasferire nuovamente l'intero progetto, il che è uno spreco di tempo e di larghezza di banda. In alternativa si può passare alla directory in cui si sa che alcuni file sono stati modificati e trasferire solo quelli con certe date di modifica. Questo è un lavoro che richiede tempo, ed è suscettibile di errori. Inoltre, il sito web può diventare non disponibile o restituire errori durante il tempo del trasferimento. 
+L'invio della cartella principale di un progetto tramite FTP va bene per il primo trasferimento, ma quando si ha bisogno di caricare un aggiornamento dell'applicazione, in cui sono cambiati solo alcuni file, l'FTP non è l'ideale. È necessario trasferire nuovamente l'intero progetto, il che è uno spreco di tempo e di larghezza di banda. In alternativa si può passare alla directory in cui si sa che alcuni file sono stati modificati e trasferire solo quelli con certe date di modifica. Questo è un lavoro che richiede tempo ed è suscettibile di errori. Inoltre, il sito web può diventare non disponibile o restituire errori durante il tempo del trasferimento. 
 
-La soluzione supportata da symfony è la sincronizzazione rsync attraverso SSH. [Rsync] (http://samba.anu.edu.au/rsync/) è una utility a riga di comando che consente il trasferimento incrementale di file in modo veloce, ed è open source. Con il trasferimento incrementale, solo i dati modificati verranno inviati. Se un file non è stato modificato, non sarà inviato all'host. Se un file è stato modificato solo in parte, sarà inviata solo la parte cambiata. Il vantaggio principale è che la sincronizzazione con rsync trasferire solo una piccola quantità di dati ed è molto veloce.
+La soluzione supportata da symfony è la sincronizzazione rsync attraverso SSH. [Rsync] (http://samba.anu.edu.au/rsync/) è una utility a riga di comando che consente il trasferimento incrementale di file in modo veloce ed è open source. Con il trasferimento incrementale, solo i dati modificati verranno inviati. Se un file non è stato modificato, non sarà inviato all'host. Se un file è stato modificato solo in parte, sarà inviata solo la parte cambiata. Il vantaggio principale è che la sincronizzazione con rsync trasferire solo una piccola quantità di dati ed è molto veloce.
 
 Symfony aggiunge l'SSH ad rsync per mettere in sicurezza il trasferimento dei dati. Sempre più host commerciali supportano un tunnel SSH per mettere in sicurezza l'upload dei file sui loro server e questa è una buona pratica per evitare problemi di sicurezza.
 
@@ -612,8 +612,8 @@ Non dimenticarsi di cancellare la cache nel server di produzione dopo la sincron
 
 Quando si sincronizza il progetto symfony con un host di produzione, alcuni file e cartelle non dovrebbero essere trasferiti: 
 
-  * Tutte le cartelle del controllo di versione (`.svn/`, `CVS/` e così via) ed il loro contenuto, sono necessari solo per lo sviluppo.
-  * Il front controller dell'ambiente di sviluppo non deve essere disponibile all'utente finale. Gli strumenti per il debug e i log disponibili quando si usa l'applicazione attraverso questo front controller rallentano l'applicazione e forniscono informazioni sulle variabili delle azioni. E' qualcosa da tenere lontano dal pubblico dominio.
+  * Tutte le cartelle del controllo di versione (`.svn/`, `CVS/` e così via) e il loro contenuto, sono necessari solo per lo sviluppo.
+  * Il front controller dell'ambiente di sviluppo non deve essere disponibile all'utente finale. Gli strumenti per il debug e i log disponibili quando si usa l'applicazione attraverso questo front controller rallentano l'applicazione e forniscono informazioni sulle variabili delle azioni. È qualcosa da tenere lontano dal pubblico dominio.
   * Le cartelle `cache/` e `log/` del progetto nel server host non devono essere cancellate ogni volta che si fa una sincronizzazione. Queste cartelle devono essere ignorate. Se si ha una cartella `stats/`, anche questa probabilmente dovrebbe essere trattata allo stesso modo.
   * I file caricati  dagli utenti non dovrebbero essere trasferiti. Una delle buone pratiche per i progetti symfony è di memorizzare i file caricati nella cartella `web/uploads/`. Questo permette di escludere tutti questi file dalla sincronizzazione indicando una sola cartella.
 
@@ -681,6 +681,6 @@ Il task `project:enable` riabilita l'applicazione e cancella la cache.
 Riepilogo
 ---------
 
-Combinando i log di PHP con quelli di symfony, è possibile monitorare ed eseguire il debug dell'applicazione facilmente. Durante lo sviluppo, la modalità di debug, le eccezioni, e la barra web di debug aiutano ad individuare i problemi. Per facilitare il debug è anche possibile inserire messaggi personalizzati nei file di log o nella barra degli strumenti.
+Combinando i log di PHP con quelli di symfony, è possibile monitorare ed eseguire il debug dell'applicazione facilmente. Durante lo sviluppo, la modalità di debug, le eccezioni, e la barra web di debug aiutano a individuare i problemi. Per facilitare il debug è anche possibile inserire messaggi personalizzati nei file di log o nella barra degli strumenti.
 
 L'interfaccia a riga di comando fornisce un gran numero di strumenti che facilitano la gestione delle applicazioni, durante le fasi di sviluppo e di produzione. Tra gli altri, i task per il popolamento dei dati e quello per la sincronizzazione fanno risparmiare molto tempo.
diff --git a/gentle-introduction/it/17-Extending-Symfony.markdown b/gentle-introduction/it/17-Extending-Symfony.markdown
index 956340f..0bc2c63 100644
--- a/gentle-introduction/it/17-Extending-Symfony.markdown
+++ b/gentle-introduction/it/17-Extending-Symfony.markdown
@@ -1,4 +1,4 @@
-Capitolo 17 - Estendere Symfony
+Capitolo 17 - Estendere symfony
 ===============================
 
 A volte è necessario modificare il comportamento di symfony. Può accadere di dover modificare il modo in cui una certa classe si comporta o aggiungere delle caratteristiche personalizzate e ciò avverrà inevitabilmente perché ogni cliente ha esigenze specifiche che nessun framework può prevedere. In realtà, questa situazione è così comune che symfony fornisce un meccanismo per estendere classi esistenti in fase di runtime, al di là della semplice ereditarietà delle classi. È anche possibile sostituire le classi del core di symfony modificando le impostazioni di fabbrica. Una volta si è scrita una estensione, si può facilmente pacchettizzarla come plug-in, in modo che possa essere riutilizzata in altre applicazioni, o da altri utenti di symfony.
@@ -10,7 +10,7 @@ PHP non supporta l'ereditarietà multipla, il che significa che non è possibile
 
 ### Capire gli eventi
 
-Alcune classi di symfony "notificano un evento al dispatcher" in vari momenti della loro vita. Per esempio, quando l'utente cambia la cultura, l'oggetto utente notifica che si è verificato un evento `change_culture`. E' come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Potete fare quello che volete a questo riguardo".
+Alcune classi di symfony "notificano un evento al dispatcher" in vari momenti della loro vita. Per esempio, quando l'utente cambia la cultura, l'oggetto utente notifica che si è verificato un evento `change_culture`. È come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Potete fare quello che volete a questo riguardo".
 
 Si può decidere di fare qualcosa di speciale quando un evento viene generato. Per esempio, è possibile salvare la cultura utente in una tabella di database ogni volta che si verifica l'evento `change_culture`. Per fare ciò, è necessario *registrare un ascoltatore di eventi*, in altri termini è necessario dichiarare una funzione che verrà chiamata al verificarsi dell'evento. Il Listato 17-1 mostra come registrare un ascoltatore per l'evento `change_culture` dell'utente.
 
@@ -39,7 +39,7 @@ Una volta che la funzione è registrata con il dispatcher di eventi, aspetta fin
 
 L'oggetto evento memorizza le informazioni sugli eventi notificati. L'evento notificante può essere recuperato grazie al metodo `getSubject()` e i parametri dell'evento sono accessibili mediante l'oggetto evento come array (per esempio, `$event['culture']` può essere utilizzato per recuperare il parametro `culture` passato da` sfUser` quando viene notificato `user.change_culture`).
 
-Per concludere, il sistema degli eventi permette di aggiungere capacità ad una classe esistente o modificare i suoi metodi in fase di runtime, senza usare l'ereditarietà.
+Per concludere, il sistema degli eventi permette di aggiungere capacità a una classe esistente o modificare i suoi metodi in fase di runtime, senza usare l'ereditarietà.
 
 ### Notificare un ascoltatore di eventi
 
@@ -82,11 +82,11 @@ Listato 17-2 - Notificare un ascoltatore di eventi
       }
     }
 
-Il metodo `notify()` del dispatcher di eventi si aspetta un oggetto `sfEvent` come argomento; è l'oggetto stesso che viene passato agli ascoltatori di eventi. Questo oggetto porta sempre un riferimento al notificatore (è per questo che l'istanza dell'evento viene inizializzata con `this`) ed un identificativo di evento. Facoltativamente, accetta un array associativo di parametri, dando agli ascoltatori un modo per interagire con la logica del notificante.
+Il metodo `notify()` del dispatcher di eventi si aspetta un oggetto `sfEvent` come argomento; è l'oggetto stesso che viene passato agli ascoltatori di eventi. Questo oggetto porta sempre un riferimento al notificatore (è per questo che l'istanza dell'evento viene inizializzata con `this`) e un identificativo di evento. Facoltativamente, accetta un array associativo di parametri, dando agli ascoltatori un modo per interagire con la logica del notificante.
 
 ### Notifica di un evento al dispatcher finché un ascoltatore lo prende in carico
 
-Usando il metodo `notify()`, si è sicuri che tutti gli ascoltatori registrati sull'evento da notificare vengono eseguiti. Tuttavia, in alcuni casi è necessario consentire ad un ascoltatore di fermare l'evento e prevenire che ulteriori ascoltatori possano fare notifiche su di esso. In questo caso, si dovrebbe usare `notifyUntil()` al posto di `notify()`. Il dispatcher eseguirà tutti gli ascoltatori fino a quando uno di questi ritorna `true` e quindi fermerà la notifica degli eventi. In altre parole, `notifyUntil()` è come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Se qualcuno se ne occupa, allora non lo dirò a nessun altro". Il Listato 17-3 mostra come usare questa tecnica in combinazione con un metodo magico `__call()` per aggiungere metodi a una classe esistente in fase di runtime.
+Usando il metodo `notify()`, si è sicuri che tutti gli ascoltatori registrati sull'evento da notificare vengono eseguiti. Tuttavia, in alcuni casi è necessario consentire a un ascoltatore di fermare l'evento e prevenire che ulteriori ascoltatori possano fare notifiche su di esso. In questo caso, si dovrebbe usare `notifyUntil()` al posto di `notify()`. Il dispatcher eseguirà tutti gli ascoltatori fino a quando uno di questi ritorna `true` e quindi fermerà la notifica degli eventi. In altre parole, `notifyUntil()` è come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Se qualcuno se ne occupa, allora non lo dirò a nessun altro". Il Listato 17-3 mostra come usare questa tecnica in combinazione con un metodo magico `__call()` per aggiungere metodi a una classe esistente in fase di runtime.
 
 Listato 17-3 - Notifica di un evento finché l'ascoltatore restituisce true
 
@@ -112,7 +112,7 @@ Listato 17-3 - Notifica di un evento finché l'ascoltatore restituisce true
 
 Un ascoltatore di eventi registrato sull'evento `rest_request.method_not_found`, può verificare la richiesta `$method` e decidere di gestirla, o passare al prossimo ascoltatore di eventi callable. Nel Listato 17-4, si può vedere come una classe creata da altri può aggiungere dei metodi `put()` e `delete()` alla classe `sfRestRequest` in fase di runtime con questo trucco.
 
-Listato 17-4 - Gestire un evento del tipo "notificare finchè"
+Listato 17-4 - Gestire un evento del tipo "notificare finché"
 
     [php]
     class frontendConfiguration extends sfApplicationConfiguration
@@ -162,9 +162,9 @@ Listato 17-4 - Gestire un evento del tipo "notificare finchè"
       }
     }
 
-In pratica, `notifyUntil()` aggiunge funzionalità di ereditarietà multipla, o meglio mixin (l'aggiunta di metodi da parte di classi esterne rispetto ad una classe esistente), al PHP. Quindi ora si possono "iniettare" nuovi metodi agli oggetti che non si possono estendere atrtaverso l'ereditarietà. E questo avviene a runtime. Non si è più limitati dalle capacità orientate agli oggetti di PHP quando si utilizza symfony.
+In pratica, `notifyUntil()` aggiunge funzionalità di ereditarietà multipla, o meglio mixin (l'aggiunta di metodi da parte di classi esterne rispetto a una classe esistente), al PHP. Quindi ora si possono "iniettare" nuovi metodi agli oggetti che non si possono estendere atrtaverso l'ereditarietà. E questo avviene a runtime. Non si è più limitati dalle capacità orientate agli oggetti di PHP quando si utilizza symfony.
 
->**TIP**: Essendo che il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo ad essere registrato, è il primo ad essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi ad una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
+>**TIP**: Essendo che il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo ad essere registrato, è il primo ad essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi a una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
 
 ### Cambiare il valore di ritorno di un metodo
 
@@ -382,7 +382,7 @@ Alcuni di questi plugin sono stati creati dalla comunità, mentre altri provengo
 
   * `sfFeed2Plugin`: Automatizza la manipolazione dei feed RSS e Atom
   * `sfThumbnailPlugin`: Crea miniature, ad esempio per le immagini caricate da web
-  * `sfMediaLibraryPlugin`: Permette il caricamento e la gestione di file, ed include una estensione per un editor di testo avanzato che permette la creazione di immagini all'interno di un testo con formattazione grafica
+  * `sfMediaLibraryPlugin`: Permette il caricamento e la gestione di file e include una estensione per un editor di testo avanzato che permette la creazione di immagini all'interno di un testo con formattazione grafica
   * `sfGuardPlugin`: Fornisce funzionalità per la gestione degli utenti, come autenticazione, autorizzazione di accesso e altre che si collocano sopra le funzionalità di sicurezza predefinite di symfony
   * `sfSuperCachePlugin`: Scrive le pagine della cartella cache, sotto la cartella radice principale per il web, per consentire al server web di accedervi il più velocemente possibile
   * `sfErrorLoggerPlugin`: Salva nel database ogni errore 404 e 500 e fornisce un modulo amministrativo per visualizzare questi errori
@@ -476,10 +476,10 @@ Listato 17-15 - Attivazione del modulo di un plugin, in `frontend/config/setting
       .settings:
         enabled_modules:  [default, sfMyPluginModule]
 
-Questo per evitare una situazione in cui il modulo di un plugin è erroneamente reso disponibile per una applicazione che non lo richiede, che potrebbe aprire un buco nella sicurezza. Pensiamo ad un plug-in che fornisce i moduli `frontend` e `backend`. Sarà necessario abilitare il modulo `frontend` solo nell'applicazione `frontend` e il modulo `backend` solo nell'applicazione `backend`. Questo è il motivo per cui i moduli dei plug-in, nella modalità predefinita non sono attivati.
+Questo per evitare una situazione in cui il modulo di un plugin è erroneamente reso disponibile per una applicazione che non lo richiede, che potrebbe aprire un buco nella sicurezza. Pensiamo a un plug-in che fornisce i moduli `frontend` e `backend`. Sarà necessario abilitare il modulo `frontend` solo nell'applicazione `frontend` e il modulo `backend` solo nell'applicazione `backend`. Questo è il motivo per cui i moduli dei plug-in, nella modalità predefinita non sono attivati.
 
 >**TIP**
->Il modulo default è l'unico modulo che viene abilitato in modalità predefinita. In realtà non è un vero modulo di plugin, perché risiede nel framework, in `sfConfig::get('sf_symfony_lib_dir')/controller/default/`. E' il modulo che fornisce le pagine di congratulazioni e le pagine di errore predefinite per gli errori 404 e la richiesta credenziali. Se non si desidera utilizzare le pagine predefinite di symfony, è sufficiente rimuovere il modulo dall'impostazione `enabled_modules`.
+>Il modulo default è l'unico modulo che viene abilitato in modalità predefinita. In realtà non è un vero modulo di plugin, perché risiede nel framework, in `sfConfig::get('sf_symfony_lib_dir')/controller/default/`. È il modulo che fornisce le pagine di congratulazioni e le pagine di errore predefinite per gli errori 404 e la richiesta credenziali. Se non si desidera utilizzare le pagine predefinite di symfony, è sufficiente rimuovere il modulo dall'impostazione `enabled_modules`.
 
 #### Visualizzare l'elenco dei plugin installati
 
@@ -576,7 +576,7 @@ Listato 17-19 - Esempio della dichiarazione di uno schema di Propel in un plugin
   * Gli helper vengono trovati automaticamente quando si chiama `use_helper()` nei template. Essi devono essere in una sotto cartella `helper/` di una delle cartelle `lib/` del plugin.
   * Se si usa Propel, le classi del modello in `myplugin/lib/model/` specializzano le classi del modello generate dal generatore di Propel (in `myplugin/lib/model/om/` and `myplugin/lib/model/map/`) . Essi sono, ovviamente, caricate automaticamente. Bisogna essere a conoscenza che non è possibile sovrascrivere le classi del modello generato di un plug-in, nelle cartelle del proprio progetto.
   * Se si usa Doctrine, l'ORM genera le classi base dei plugin in `myplugin/lib/model/Plugin*. class.php` e le classi reali in `lib/model/myplugin/`. Questo significa che si possono sovrascrivere facilmente le classi del modello nella propria applicazione.
-  * I task sono immediatamente disponibili per la riga di comando di symfony non appena il plug-in viene installato. Un plugin può aggiungere nuovi task o sovrascriverne uno esistente. E' buona pratica usare il nome del plugin come spazio dei nomi per il task. Digitare `php symfony` per visualizzare l'elenco dei task disponibili, inclusi quelli aggiunti dai plugin.
+  * I task sono immediatamente disponibili per la riga di comando di symfony non appena il plug-in viene installato. Un plugin può aggiungere nuovi task o sovrascriverne uno esistente. È buona pratica usare il nome del plugin come spazio dei nomi per il task. Digitare `php symfony` per visualizzare l'elenco dei task disponibili, inclusi quelli aggiunti dai plugin.
   * I moduli forniscono nuove azioni accessibili dall'esterno, a condizione che li si dichiari impostandoli in `enabled_modules` nell'applicazione.
   * Le risorse web (immagini, script, fogli di stile, ecc) sono messe a disposizione del server. Quando si installa un plug-in tramite la riga di comando, symfony crea un link simbolico alla cartella `web/` del progetto, se il sistema lo consente, o copia il contenuto della cartella `web/` del modulo nel progetto. Se il plugin è installato da un archivio o un repository di controllo della versione, è necessario copiare la cartella `web/` del plugin a mano (come dovrebbe indicare il file `README` incluso nel plug-in).
 		  
@@ -730,7 +730,7 @@ Listato 17-21 - Personalizzare l'azione di un plugin
 
 ### Come scrivere un plugin
 
-Solo i plugin pacchettizzati con PEAR possono essere installati con il task `plugin:install`. E' bene ricordare che tali plugin possono essere distribuiti attraverso la sezione plugin di symfony, un canale PEAR, o un semplice file per il download. Quindi se si vuole scrivere un plugin, è meglio pubblicarlo come pacchetto PEAR che come semplice file di archivio. Inoltre, i plugin che utilizzano PEAR sono più facili da aggiornare, possono dichiarare dipendenze e fare il deploy in automatico delle risorse nella cartella `web/`.
+Solo i plugin pacchettizzati con PEAR possono essere installati con il task `plugin:install`. È bene ricordare che tali plugin possono essere distribuiti attraverso la sezione plugin di symfony, un canale PEAR, o un semplice file per il download. Quindi se si vuole scrivere un plugin, è meglio pubblicarlo come pacchetto PEAR che come semplice file di archivio. Inoltre, i plugin che utilizzano PEAR sono più facili da aggiornare, possono dichiarare dipendenze e fare il deploy in automatico delle risorse nella cartella `web/`.
 
 #### Organizzazione dei file
 
@@ -778,7 +778,7 @@ Per la creazione, la posizione della cartella del plugin (`sfEsempioPlugin/` nel
 
 #### Creazione del file package.xml
 
-Il prossimo passo nella creazione del plugin è quello di aggiungere un file package.xml nella radice della cartella con il plugin. Il file `package.xml` segue la sintassi di PEAR. Dare un'occhiata ad un tipico `package.xml` di un plugin di symfony nel Listato 17-23.
+Il prossimo passo nella creazione del plugin è quello di aggiungere un file package.xml nella radice della cartella con il plugin. Il file `package.xml` segue la sintassi di PEAR. Dare un'occhiata a un tipico `package.xml` di un plugin di symfony nel Listato 17-23.
 
 Listato 17-23 - Esempio di file `package.xml` per un plugin di symfony
 
@@ -893,7 +893,7 @@ I plug-in sono progettati per funzionare con un dato insieme di versioni di PHP,
 
 È sempre necessario dichiarare le dipendenze da PHP, PEAR e symfony, almeno quelle corrispondenti alla propria installazione, come requisito minimo. Se non si sa cosa mettere, aggiungere un requisito per PHP 5.2.4, PEAR 1.4, e symfony 1.3.
 
-Si raccomanda inoltre di aggiungere un numero massimo di versione symfony per ogni plugin. Ciò causerà un messaggio di errore quando si tenta di utilizzare un plugin con una versione più avanzata del framework e questo obbligherà l'autore del plugin ad assicurarsi che il plug-in funzioni correttamente con questa versione prima del nuovo rilascio. E' meglio avere una segnalazione e scaricare un aggiornamento piuttosto che avere un plugin che fallisce silenziosamente.
+Si raccomanda inoltre di aggiungere un numero massimo di versione symfony per ogni plugin. Ciò causerà un messaggio di errore quando si tenta di utilizzare un plugin con una versione più avanzata del framework e questo obbligherà l'autore del plugin ad assicurarsi che il plug-in funzioni correttamente con questa versione prima del nuovo rilascio. È meglio avere una segnalazione e scaricare un aggiornamento piuttosto che avere un plugin che fallisce silenziosamente.
 
 Se si specificano plugin come dipendenze, gli utenti saranno in grado di installare il plugin e tutte le sue dipendenze con un singolo comando:
 

From f3781ba1fcb3932e1cb7fc28f882d6a13dda669a Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Fri, 30 Jul 2010 11:14:26 +0200
Subject: [PATCH 02/10] fixed 5

---
 .../it/05-Configuring-Symfony.markdown        | 275 +++++++++---------
 1 file changed, 145 insertions(+), 130 deletions(-)

diff --git a/gentle-introduction/it/05-Configuring-Symfony.markdown b/gentle-introduction/it/05-Configuring-Symfony.markdown
index c2d7fc8..d242ef6 100644
--- a/gentle-introduction/it/05-Configuring-Symfony.markdown
+++ b/gentle-introduction/it/05-Configuring-Symfony.markdown
@@ -1,20 +1,20 @@
 Capitolo 5 - Configurare symfony
 ================================
 
-Per essere semplice da usare, symfony definisce alcune convenzioni, che devono soddisfare i requisiti più comuni nello sviluppo web senza bisogno di modifiche. Comunque, utilizzando un insieme di semplici e potenti file di configurazione, è possibile personalizzare il modo in cui il framework e la tua applicazione interagiscono fra loro. Con questi file di configurazione, potrai anche aggiungere parametri speciali alla tua applicazione.
+Per essere semplice da usare, symfony definisce alcune convenzioni, che devono soddisfare i requisiti più comuni nello sviluppo web senza bisogno di modifiche. Comunque, utilizzando un insieme di semplici e potenti file di configurazione, è possibile personalizzare il modo in cui il framework e la propria applicazione interagiscono fra loro. Con questi file di configurazione, si potranno anche aggiungere parametri speciali alla propria applicazione.
 
 Questo capitolo spiega come funziona il sistema di configurazione:
 
   * La configurazione di symfony è memorizzata in file scritti in YAML, anche se è sempre possibile scegliere un altro formato.
-  * Nella struttura di cartelle del progetto, i file di configurazione si trovano ai livelli progetto, applicazione e modulo.
-  * Puoi definire diversi insiemi di impostazioni; in symfony, un insieme di configurazioni è chiamato ambiente.
-  * I valori definiti nei file di configurazione sono disponibili al codice PHP della tua applicazione.
+  * Nella struttura di cartelle del progetto, i file di configurazione si trovano a livello di progetto, applicazione e modulo.
+  * Si possono definire diversi insiemi di impostazioni: in symfony, un insieme di configurazioni è chiamato ambiente.
+  * I valori definiti nei file di configurazione sono disponibili al codice PHP della propria applicazione.
   * Inoltre, symfony permette l'utilizzo di codice PHP e altri trucchi all'interno dei file di configurazione YAML, per rendere il sistema di configurazione ancora più flessibile.
 
 Il Sistema di configurazione
 ----------------------------
 
-A parte lo scopo, la maggior parte delle applicazioni web condivide un insieme di caratteristiche comuni. Ad esempio, qualche sezione può avere accesso ristretto a un certo insieme di utenti, oppure le pagine possono essere decorate da un layout, o ancora la possibilità di avere le form già riempite dopo una validazione fallita. Un framework definisce una struttura per simulare queste caratteristiche e gli sviluppatori possono ulteriormente modificarle cambiando i file di configurazione. Questa strategia fa risparmiare molto tempo durante lo sviluppo, dato che molti cambiamenti non necessitano di alcuna linea di codice, anche se ce n'è molto dietro. Questo sistema è anche molto efficiente, perché assicura che queste informazioni siano reperibili sempre in un punto unico e facile da trovare.
+A parte lo scopo, la maggior parte delle applicazioni web condivide un insieme di caratteristiche comuni. Ad esempio, qualche sezione può avere accesso ristretto a un certo insieme di utenti, oppure le pagine possono essere decorate da un layout, o ancora la possibilità di avere i form già riempiti dopo una validazione fallita. Un framework definisce una struttura per simulare queste caratteristiche e gli sviluppatori possono ulteriormente modificarle cambiando i file di configurazione. Questa strategia fa risparmiare molto tempo durante lo sviluppo, dato che molti cambiamenti non necessitano di alcuna linea di codice, anche se ce n'è molto dietro. Questo sistema è anche molto efficiente, perché assicura che queste informazioni siano reperibili sempre in un punto unico e facile da trovare.
 
 Questo approccio ha però due seri svantaggi:
 
@@ -26,14 +26,14 @@ Tenendo conto di questi svantaggi, symfony utilizza file di configurazione solo
   * Potente: ogni aspetto che possa essere gestito tramite file di configurazione lo è veramente.
   * Semplice: diversi parametri di configurazione non sono mostrati in una normale applicazione, in quanto raramente necessitano di essere modificati.
   * Facile: gli sviluppatori troveranno facile leggere, creare e modificare file di configurazione.
-  * Personalizzabile: il linguaggio di configurazione di default è YAML, ma puo' essere INI, XML, o qualsiasi altro formato lo sviluppatore preferisca.
+  * Personalizzabile: il linguaggio di configurazione di default è YAML, ma puo' essere INI, XML o qualsiasi altro formato lo sviluppatore preferisca.
   * Veloce: i file di configurazione non vengono processati dall'applicazione ma dal sistema di configurazione, che li compila velocemente in parti di codice PHP sul server.
 
 ### Sintassi YAML e convenzioni di symfony
 
-Per la propria configurazione, symfony utilizza il formato YAML, invece dei più tradizionali INI e XML. YAML mostra la struttura tramite indentazione ed è veloce da scrivere. I vantaggi e le regole di base sono già state mostrate nel Capitolo 1. Comunque, devi tenere a mente qualche convenzione quando vuoi scrivere file di YAML. Questa sezione introduce diverse convenzioni tra le più importanti. Per approfondimenti visita il sito web di YAML [website](http://www.yaml.org/).
+Per la sua configurazione, symfony utilizza il formato YAML, invece dei più tradizionali INI e XML. YAML mostra la struttura tramite indentazione ed è veloce da scrivere. I vantaggi e le regole di base sono già state mostrate nel Capitolo 1. Comunque, occorre tenere a mente qualche convenzione quando si scrivono file YAML. Questa sezione introduce diverse convenzioni tra le più importanti. Per approfondimenti, visitare il [sito web di YAML](http://www.yaml.org/).
 
-Prima di tutto non sono ammessi caratteri di tabulazione in YAML; occorre usare spazi bianchi. I parser YAML non capiscono le tabulazioni, per cui utilizza spazi bianchi per l'indentazione (la convenzione in symfony è di due spazi bianchi), come mostrato nel Listato 5-1.
+Prima di tutto non sono ammessi caratteri di tabulazione in YAML: occorre usare spazi vuoti. I parser YAML non capiscono le tabulazioni, per cui si devono utilizzare spazi vuoti per l'indentazione (la convenzione in symfony è di due spazi), come mostrato nel Listato 5-1.
 
 Listato 5-1 - YAML vieta l'utilizzo delle tabulazioni
 
@@ -48,7 +48,7 @@ Listato 5-1 - YAML vieta l'utilizzo delle tabulazioni
         webmaster: webmaster@example.com
 
 
-Se i tuoi parametri sono stringhe che cominciano o finiscono con spazi vuoti, contengono caratteri speciali (come # o ,), o sono parole chiave come "true, false" (intese come una stringa), devi incapsulare il valore tra singoli apici, come mostrato nel Listato 5-2.
+Se i parametri sono stringhe che cominciano o finiscono con spazi vuoti, contengono caratteri speciali (come # o ,) o sono parole chiave come "true, false" (intese come una stringa), occorre incapsulare il valore tra singoli apici, come mostrato nel Listato 5-2.
 
 Listato 5-2 - Stringhe non standard dovrebbero essere incapsulate tra singoli apici
 
@@ -59,7 +59,7 @@ Listato 5-2 - Stringhe non standard dovrebbero essere incapsulate tra singoli ap
     i18n:   'false' # se togliamo gli apici, viene restituito un valore booleano false
 
 
-Puoi definire stringhe lunghe in più righe e anche stringhe con più di una linea, con gli header speciali di stringa (> e |) più una indentazione addizionale. Il Listato 5-3 illustra questa convenzione.
+Si possono definire stringhe lunghe in più righe e anche stringhe con più di una linea, con gli header speciali di stringa (> e |) più una indentazione addizionale. Il Listato 5-3 illustra questa convenzione.
 
 Listato 5-3 - Definizione di stringhe lunghe e su più righe
 
@@ -77,7 +77,7 @@ Listato 5-3 - Definizione di stringhe lunghe e su più righe
       65 Home Runs
       0.278 Batting Average
 
-Per definire un valore come array, racchiudi gli elementi tra parentesi quadre, oppure usa la sintassi estesa con i trattini, come mostrato nel Listato 5-4.
+Per definire un valore come array, racchiudere gli elementi tra parentesi quadre, oppure usare la sintassi estesa con i trattini, come mostrato nel Listato 5-4.
 
 Listato 5-4 - Sintassi di array in YAML
 
@@ -90,11 +90,11 @@ Listato 5-4 - Sintassi di array in YAML
       - Sammy Sosa
       - Ken Griffey
 
-Per definire un valore come array associativo, o hash, racchiudi gli elementi tra parentesi graffe e inserisci sempre uno spazio tra la chiave e il valore nella coppia 'key: value' e separa gli elementi della lista con delle virgole. Puoi anche utilizzare la sintassi estesa, aggiungendo indentazione e ritorno a capo per ogni chiave, come mostrato nel Listato 5-5.
+Per definire un valore come array associativo, o hash, racchiudere gli elementi tra parentesi graffe e inserire sempre uno spazio tra la chiave e il valore nella coppia 'key: value' e separare gli elementi della lista con delle virgole. Si può anche utilizzare la sintassi estesa, aggiungendo indentazione e ritorno a capo per ogni chiave, come mostrato nel Listato 5-5.
 
 Listato 5-5 - Array associativi in YAML
 
-    # Sintassi errata: mancano gli spazi dopo i duepunti e la virgola
+    # Sintassi errata: mancano gli spazi dopo i due-punti e la virgola
     mail: {webmaster:webmaster@example.com,contact:contact@example.com}
 
     # Sintassi abbreviata corretta per gli array associativi
@@ -106,7 +106,7 @@ Listato 5-5 - Array associativi in YAML
       contact: contact@example.com
 
 
-Per assegnare un valore booleano, utilizza i valori `false` e `true`
+Per assegnare un valore booleano, utilizzare i valori `false` e `true`
 senza apici.
 
 Listato 5-6 - Sintassi YAML per valori booleani
@@ -114,7 +114,7 @@ Listato 5-6 - Sintassi YAML per valori booleani
     true_value: true
     false_value: false
 
-Non esitare ad aggiungere commenti (che devono cominciare con il cancelletto #) e spazi aggiuntivi, per rendere ancora più leggibili tuoi file YAML, come mostrato nel Listato 5-7.
+Si possono aggiungere commenti (che devono cominciare con il cancelletto #) e spazi aggiuntivi, per rendere ancora più leggibili i file YAML, come mostrato nel Listato 5-7.
 
 Listato 5-7 - Sintassi dei commenti e allineamento dei valori in YAML
 
@@ -124,19 +124,19 @@ Listato 5-7 - Sintassi dei commenti e allineamento dei valori in YAML
       contact:   contact@example.com
       admin:     admin@example.com # gli spazi aggiuntivi permettono un migliore allineamento dei valori
 
-In qualche file di configurazione di symfony, ti capiterà di trovare delle linee che cominciano con un cancelletto (per cui ignorate dal parser YAML) e che assomigliano a normali linee di impostazioni. Questa è una convenzione di symfony: la configurazione di default, ereditata da altri file YAML che si trovano nel core, è ripetuta in linee commentate nella tua applicazione per pura informazione. Se vuoi cambiare uno di tali parametri, devi innanzitutto decommentare la linea, come mostrato nel Listato 5-8.
+In qualche file di configurazione di symfony capiterà di trovare delle linee che cominciano con un cancelletto (per cui ignorate dal parser YAML) e che assomigliano a normali linee di impostazioni. Questa è una convenzione di symfony: la configurazione predefinita, ereditata da altri file YAML che si trovano nel core, è ripetuta in linee commentate nella propria applicazione per pura informazione. Se si vuole cambiare uno di tali parametri, occorre innanzitutto scommentare la linea, come mostrato nel Listato 5-8.
 
-Listato 5-8 - La configurazione di default è mostrata commentata
+Listato 5-8 - La configurazione predefinita è mostrata commentata
 
     # La cache è false per default
     settings:
     # cache: false
 
-    # Se vuoi cambiare questa impostazioni, decommenta la linea
+    # Se si vogliono cambiare questa impostazioni, scommentare la linea
     settings:
       cache: true
 
-Qualche volta symfony raggruppa le definizioni dei parametri in categorie. Tutte le impostazioni relative a una data categoria appaiono indentati sotto il suo header. Strutturare lunghe liste di coppie chiave: valore raggruppandole in categorie aumenta la leggibilità della configurazione. Gli header di categoria cominciano con un punto (.). Il Listato 5-9 mostra un esempio di categorie.
+Qualche volta symfony raggruppa le definizioni dei parametri in categorie. Tutte le impostazioni relative a una data categoria appaiono indentati sotto il suo header. Strutturare lunghe liste di coppie chiave/valore raggruppandole in categorie aumenta la leggibilità della configurazione. Gli header di categoria cominciano con un punto (.). Il Listato 5-9 mostra un esempio di categorie.
 
 Listato 5-9 - Gli header di categoria sembrano chiavi, ma cominciano con un un punto
 
@@ -147,7 +147,7 @@ Listato 5-9 - Gli header di categoria sembrano chiavi, ma cominciano con un un p
           mail:
             webmaster: webmaster@example.com
 
-In questo esempio, mail è una chiave e general è solo un header di categoria. Tutto funziona come se l'header non esistesse, come mostrato nel Listato 5-10. Il parametro tax è effettivamente un figlio diretto della chiave all. Tuttavia l'uso delle categorie aiuta symfony a trattare con gli array che sono sotto la chiave all.
+In questo esempio, `mail` è una chiave e `general` è solo un header di categoria. Tutto funziona come se l'header non esistesse, come mostrato nel Listato 5-10. Il parametro `tax` è effettivamente un figlio diretto della chiave `all`. Tuttavia l'uso delle categorie aiuta symfony a trattare con gli array che sono sotto la chiave `all`.
 
 Listato 5-10 - Gli header di categoria esistono solo per una questione di leggibilità e sono in effetti ignorati
 
@@ -158,19 +158,19 @@ Listato 5-10 - Gli header di categoria esistono solo per una questione di leggib
       webmaster: webmaster@example.com
 
 >**SIDEBAR**
->E se non ti piace YAML...
+>E se YAML non va bene...
 >
->YAML è solo un'interfaccia per definire impostazioni utilizzate da PHP, per cui le configurazioni YAML finiscono per essere trasformate in PHP. Dopo aver navigato la tua applicazione, controllane la configurazione in cache (ad esempio in cache/frontend/dev/config/). Vedrai file PHP corrispondenti alle configurazioni YAML. Imparerai di più sulla cache di configurazione più avanti in questo capitolo.
+>YAML è solo un'interfaccia per definire impostazioni utilizzate da PHP, per cui le configurazioni YAML finiscono per essere trasformate in PHP. Dopo aver navigato la propria applicazione, se ne può controllare la configurazione in cache (ad esempio in cache/frontend/dev/config/). Si vedranno file PHP corrispondenti alle configurazioni YAML. Altre informazioni sulla cache di configurazione sono disponibili più avanti in questo capitolo.
 >
->La buona notizia è che se non vuoi usare YAML, puoi fare la stessa cosa a mano in PHP o con altri formati (come XML o INI). Nel corso di questo libro, incontrerai modi alternativi per definire configurazioni senza YAML e imparerai anche come sostituire il gestore di configurazioni di symfony (nel Capitolo 19). Se li usi largamente, questi trucchi ti permetteranno di bypassare i file di configurazione o definire il tuo personale formato di configurazione.
+>La buona notizia è che se non si vuole usare YAML, si può fare la stessa cosa a mano in PHP o con altri formati (come XML o INI). Nel corso di questo libro, vedremo modi alternativi per definire configurazioni senza YAML e impareremo anche come sostituire il gestore di configurazioni di symfony (nel Capitolo 19). Usati largamente, questi trucchi permetteranno di aggirare i file di configurazione o definire il proprio personale formato di configurazione.
 
-### Aiuto, un file YAML ha ucciso la mia applicazione!
+### Aiuto, un file YAML ha ucciso l'applicazione!
 
-I file YAML sono parsati in array o hash PHP, quindi i valori sono usati in varie parti dell'applicazione per modificare il comportamento delle viste, del controller o del modello. Molte volte, quando c'è un errore in un file YAML, esso non viene riconosciuto fino a che il valore non è effettivamente necessario. Ancora più spesso, l'eccezione che viene generata non si riferisce chiaramente al file YAML.
+I file YAML sono analizzati e trasformati in array o hash PHP, quindi i valori sono usati in varie parti dell'applicazione per modificare il comportamento delle viste, del controller o del modello. Molte volte, quando c'è un errore in un file YAML, esso non viene riconosciuto fino a che il valore non è effettivamente necessario. Ancora più spesso, l'eccezione che viene generata non si riferisce chiaramente al file YAML.
 
-Se la tua applicazione smette improvvisamente di funzionare dopo un cambio di configurazione, devi controllare di non aver fatto qualcuno dei più comuni errori di disattenzione con YAML:
+Se la propria applicazione smette improvvisamente di funzionare dopo un cambio di configurazione, occorre controllare di non aver fatto qualcuno dei più comuni errori di disattenzione con YAML:
 
-  * Ti manca uno spazio tra una chiave e il suo valore:
+  * Manca uno spazio tra una chiave e il suo valore:
 
         key1:value1 # Manca uno spazio bianco dopo :
 
@@ -186,46 +186,46 @@ Se la tua applicazione smette improvvisamente di funzionare dopo un cambio di co
         message: tell him: go way   # :, [, ], { and } sono riservate in YAML
         message: 'tell him: go way' # sintassi corretta
 
-  * Stai modificando una linea commentata:
+  * Si sta modificando una linea commentata:
 
         # key: value # Questa linea è ignorata perché comincia con #
 
-  * Imposti dei valori con la stessa chiave allo stesso livello:
+  * Si stanno impostando dei valori con la stessa chiave allo stesso livello:
 
         key1: value1
         key2: value2
         key1: value3 # key1 è definita due volte, il valore è l'ultimo inserito
 
-  * Pensi che un valore sia un tipo speciale, mentre resta una stringa fino a che non sarà convertita:
+  * Si ritiene che un valore sia un tipo speciale, mentre resta una stringa fino a che non sarà convertita:
 
         income: 12,345 # Ancora una stringa, fino a che non sarà convertita
 
 Riepilogo sui file di configurazione
------------------------------------
+------------------------------------
 
-La configurazione è suddivisa in file, per oggetto. Questi file contengono definizioni di parametri, o impostazioni. Alcuni di tali parametri possono essere sovrascritti a diversi livelli (progetto, applicazione e modulo); altri sono specifici di un certo livello. I prossimi capitoli prenderanno in esame le configurazioni relativamente alle loro finalità principali, mentre il Capitolo 19 esaminerà le configurazioni avanzate.
+La configurazione è suddivisa in file, per oggetto. Questi file contengono definizioni di parametri o impostazioni. Alcuni di tali parametri possono essere sovrascritti a diversi livelli (progetto, applicazione e modulo), altri sono specifici di un certo livello. I prossimi capitoli prenderanno in esame le configurazioni relativamente alle loro finalità principali, mentre il Capitolo 19 esaminerà le configurazioni avanzate.
 
 ### Configurazione di progetto
 
-Ci sono per default pochi file di configurazione per progetto. Di seguito quelli che si trovano nella cartella myproject/config/:
+Ci sono pochi file di configurazione predefiniti per il progetto. Di seguito quelli che si trovano nella cartella `progetto/config/`:
 
-  * `ProjectConfiguration.class.php`: Questo è assolutamente il primo file incluso da ogni richiesta o comando. Contiene i percorsi ai file del framework, e può essere cambiato per usare un'installazione diversa. Vedi il Capitolo 19 per usi avanzati di questo file.
-  * `databases.yml`: Qui è dove definisci l'accesso e la connessione al database (host, login, password, nome del database, e così via). Imparerai di più su questo nel Capitolo 8. Può essere sovrascritto a livello applicazione.
-  * `properties.ini`: Questo file gestisce parametri utilizzati a linea di comando, inclusi il nome del progetto e le impostazioni di connessione a server remoti. Vedi il Capitolo 16 per un sommario delle caratteristiche di utilizzo di questo file.
+  * `ProjectConfiguration.class.php`: Questo è assolutamente il primo file incluso da ogni richiesta o comando. Contiene i percorsi ai file del framework e può essere cambiato per usare un'installazione diversa. Vedere il Capitolo 19 per usi avanzati di questo file.
+  * `databases.yml`: Qui è dove si definisce l'accesso e la connessione al database (host, login, password, nome del database e così via). Vedremo di più su questo nel Capitolo 8. Può essere sovrascritto a livello di applicazione.
+  * `properties.ini`: Questo file gestisce parametri utilizzati a linea di comando, inclusi il nome del progetto e le impostazioni di connessione a server remoti. Vedere il Capitolo 16 per un sommario delle caratteristiche di utilizzo di questo file.
   * `rsync_exclude.txt`: Questo file specifica quali cartelle e file devono essere esclusi dalla sincronizzazione tra server. È discusso nel Capitolo 16.
-  * `schema.yml`: Si tratta del file di configurazione per l'accesso ai dati usato da Propel e Doctrine (il livello ORM di symfony). Esso è usato per far funzionare le librerie dell'ORM con le classi di symfony e i dati del tuo progetto. schema.yml contiene una rappresentazione del modello relazionale del progetto.
+  * `schema.yml`: Si tratta del file di configurazione per l'accesso ai dati usato da Propel e Doctrine (gli ORM di symfony). Esso è usato per far funzionare le librerie dell'ORM con le classi di symfony e i dati del progetto. Il file `schema.yml` contiene una rappresentazione del modello relazionale del progetto. Per Doctrine, il file è in `config/doctrine/`.
 
-Questi file sono usati per lo più da componenti esterni o dalla linea di comando, o devono essere processati prima che il framework carichi il programma di parsing YAML. Ecco perché alcuni di essi non usano il formato YAML.
+Questi file sono usati per lo più da componenti esterni o dalla linea di comando o devono essere processati prima che il framework carichi il programma di analisi YAML. Ecco perché alcuni di essi non usano il formato YAML.
 
 ### Configurazione dell'applicazione
 
-La maggior parte della configurazione è occupata dall'applicazione. È definita nel front controller (nella cartella web/) per la configurazione principale, in file YAML nella cartella config/ dell'applicazione, in i18n/ per l'internazionalizzazione e infine nei file del framework per una invisibile (ma sempre utile) configurazione addizionale dell'applicazione.
+La maggior parte della configurazione è occupata dall'applicazione. È definita nel front controller (nella cartella `web/`) per la configurazione principale, in file YAML nella cartella `config/` dell'applicazione, in `i18n/` per l'internazionalizzazione e infine nei file del framework per una invisibile (ma sempre utile) configurazione ulteriore dell'applicazione.
 
 #### Configurazione del front controller
 
-La prima configurazione dell'applicazione in assoluto si trova nel front controller; si tratta del primo script eseguito da una richiesta. Dai un'occhiata al codice di web/index.php mostrato nel Listato 5-11.
+La prima configurazione dell'applicazione in assoluto si trova nel front controller. Si tratta del primo script eseguito da una richiesta. Si veda codice di `web/index.php` mostrato nel Listato 5-11.
 
-Listato 5-11 - Il front controller di default 
+Listato 5-11 - Il front controller predefinito
 
     [php]
     <?php
@@ -234,26 +234,26 @@ Listato 5-11 - Il front controller di default
     $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
     sfContext::createInstance($configuration)->dispatch();
 
-Dopo aver definito il nome dell'applicazione (frontend), l'ambiente (prod) e il modo di debug (false), la configurazione dell'applicazione è chiamata prima di creare un contesto e del dispatching. Per cui qualche metodo utile è disponibile nella classe di configurazione dell'applicazione:
+Dopo aver definito il nome dell'applicazione (`frontend`), l'ambiente (`prod`) e la modalità di debug (`false`), la configurazione dell'applicazione è chiamata prima di creare un contesto e del dispatch. Per cui qualche metodo utile è disponibile nella classe di configurazione dell'applicazione:
 
-  * `$configuration->getRootDir()`: La cartella di root del progetto (di norma dovrebbe rimanere come è di default, a meno che tu non voglia cambiare la struttura delle cartelle). 
-  * `$configuration->getApplication()`: Nome dell'applicazione nel progetto. Necessario per computare i percorsi dei file.
-  * `$configuration->getEnvironment()`: Nome dell'ambiente (prod, dev, o qualsiasi altro ambiente specifico che tu creerai ad hoc per il tuo progetto). Determinerà quali sono le impostazioni di configurazione da utilizzare. Gli ambienti sono spiegati più avanti in questo capitolo. 
+  * `$configuration->getRootDir()`: La cartella radice del progetto (di norma dovrebbe rimanere come è, a meno che non si voglia cambiare la struttura delle cartelle). 
+  * `$configuration->getApplication()`: Nome dell'applicazione nel progetto. Necessario per calcolare i percorsi dei file.
+  * `$configuration->getEnvironment()`: Nome dell'ambiente (`prod`, `dev` o qualsiasi altro ambiente specifico creato ad hoc per il progetto). Determinerà quali sono le impostazioni di configurazione da utilizzare. Gli ambienti sono spiegati più avanti in questo capitolo. 
   * `$configuration->isDebug()`: Attivazione della modalità di debug (vedere il Capitolo 16 per i dettagli). 
 
-Se vuoi cambiare uno di questi valori, probabilmente avrai bisogno di un front controller addizionale. Il prossimo capitolo spiegherà più nel dettaglio i front controller e come crearne di nuovi. 
+Se si vuole cambiare uno di questi valori, probabilmente occorrerà di un front controller addizionale. Il prossimo capitolo spiegherà più nel dettaglio i front controller e come crearne di nuovi. 
 
 #### Configurazione dell'applicazione principale
 
-La configurazione dell'applicazione principale è memorizzata in file che si trovano nella cartella myproject/apps/frontend/config/: 
+La configurazione dell'applicazione principale è memorizzata in file che si trovano nella cartella `progetto/apps/frontend/config/`: 
 
-  * app.yml: Questo file dovrebbe contenere configurazioni specifiche all'applicazione; ad esempio variabili globali che definiscono business logic o applicativa specifiche, che non hanno bisogno di essere memorizzate nel db. Tasse, costi di spedizione, indirizzi e-mail sono memorizzati spesso in questo file, che di default è vuoto.
-  * frontendConfiguration.class.php: questa classe si occupa del bootstrap dell'applicazione, quindi fa tutte le inizializzazioni di base necessarie all'applicazione per partire. È qui che puoi definire una struttura di cartelle particolare, oppure delle costanti specifiche (il Capitolo 19 ne fornirà maggiori dettagli). Estende la classe ProjectConfiguration. 
-  * factories.yml: symfony definisce le proprie classi per gestire le viste, la richiesta, la risposta, le sessioni e così via. Se invece vuoi utilizzare le tue classi personali, questo file è i posto in cui definirle (maggiori informazioni nel Capitolo 17). 
-  * filters.yml: I filtri sono porzioni di codice eseguiti per ogni richiesta. Qui è dove definisci quali filtri devono essere processati, e può essere sovrascritto in ogni modulo. Il Capitolo 6 fornisce maggiori dettagli sui filtri. 
-  * routing.yml: Le regole di routing, che permettono di trasformare una URL illeggibile in una più "intelligente", sono definite in questo file. Per nuove applicazioni, esistono poche regole di default. Il Capitolo 9 è dedicato ai link e al routing.
-  * settings.yml: Le impostazioni principali di un'applicazione symfony sono definiti in questo file. Qui è dove specifichi se la tua applicazione è internazionalizzata, qual è la lingua di default, il timeout per le richieste e se la cache è attiva o meno. Cambiando una linea di questo file puoi "spegnere" la tua applicazione, per poterla aggiornare o manutenere. Le impostazioni più comuni e il loro utilizzo sono approfonditi nel Capitolo 19. 
-  * view.yml: La struttura della vista di default (nome del layout, fogli di stile e JavaScript da includere di default, content-type di default e così via) è definita in questo file. Il Capitolo 7 approfondirà questo file. Queste impostazioni possono essere sovrascritte in ogni modulo. 
+  * `app.yml`: Questo file dovrebbe contenere configurazioni specifiche all'applicazione; ad esempio variabili globali che definiscono business logic, che non hanno bisogno di essere memorizzate nel db. Tasse, costi di spedizione, indirizzi e-mail sono memorizzati spesso in questo file, che di base è vuoto.
+  * `frontendConfiguration.class.php`: questa classe si occupa del bootstrap dell'applicazione, quindi fa tutte le inizializzazioni di base necessarie all'applicazione per partire. È qui che si può definire una struttura di cartelle particolare, oppure delle costanti specifiche (il Capitolo 19 ne fornirà maggiori dettagli). Estende la classe `ProjectConfiguration`. 
+  * `factories.yml`: symfony definisce le proprie classi per gestire le viste, la richiesta, la risposta, le sessioni e così via. Se invece si vogliono utilizzare le proprie classi personali, questo file è i posto in cui definirle (maggiori informazioni nel Capitolo 17). 
+  * `filters.yml`: I filtri sono porzioni di codice eseguiti per ogni richiesta. Qui è dove definisci quali filtri devono essere processati, e può essere sovrascritto in ogni modulo. Il Capitolo 6 fornisce maggiori dettagli sui filtri. 
+  * `routing.yml`: Le regole di routing, che permettono di trasformare un URL illeggibile in uno più "intelligente", sono definite in questo file. Per nuove applicazioni, esistono poche regole predefinite. Il Capitolo 9 è dedicato ai link e al routing.
+  * `settings.yml`: Le impostazioni principali di un'applicazione symfony sono definiti in questo file. Qui si specifica se la propria applicazione è internazionalizzata, qual è la lingua di default, il timeout per le richieste e se la cache è attiva o meno. Cambiando una linea di questo file si può "spegnere" la propria applicazione, per poterla aggiornare o manutenere. Le impostazioni più comuni e il loro utilizzo sono approfonditi nel Capitolo 19. 
+  * `view.yml`: La struttura predefinita della vista (nome del layout, fogli di stile e JavaScript da includere di default, content-type di default e così via) è definita in questo file. Il Capitolo 7 approfondirà questo file. Queste impostazioni possono essere sovrascritte in ogni modulo. 
 
 >**TIP**
 >Tutti i file di configurazione di symfony sono descritti in dettaglio nella [Guida di riferimento a symfony](http://www.symfony-project.org/reference/1_4/it/).
@@ -262,102 +262,103 @@ La configurazione dell'applicazione principale è memorizzata in file che si tro
 
 Applicazioni internazionalizzate possono mostrare le pagine in diverse lingue. Questo richiede una configurazione specifica. Ci sono due file da configurare per l'internazionalizzazione: 
 
-  * factories.yml della cartella config/ dell'applicazione: Questo file definisce il factory i18n e le opzioni generali di traduzione, come ad esempio la cultura di default per la traduzione, se le traduzioni sono in un file o nel database e il loro formato. 
-  * File di traduzione nella cartella i18n/ dell'applicazione: Questi sono fondamentalmente dei dizionari, che forniscono la traduzione delle parole utilizzate nelle template dell'applicazione in modo che le pagine mostrino testo tradotto quando un utente cambia la lingua.
+  * `factories.yml` della cartella `config/` dell'applicazione: Questo file definisce il factory i18n e le opzioni generali di traduzione, come ad esempio la cultura predefinita per la traduzione, se le traduzioni sono in un file o nel database e il loro formato. 
+  * File di traduzione nella cartella `i18n/` dell'applicazione: Questi sono fondamentalmente dei dizionari, che forniscono la traduzione delle parole utilizzate nelle template dell'applicazione in modo che le pagine mostrino testo tradotto quando un utente cambia la lingua.
   
-Nota che l'attivazione delle feature i18n è impostata nel file settings.yml. Approfondimenti a tale proposito nel Capitolo 13.
+Nota che l'attivazione delle feature i18n è impostata nel file `settings.yml`. Approfondimenti a tale proposito nel Capitolo 13.
 
 #### Configurazioni addizionali dell'applicazione
 
-Un secondo insieme di file di configurazione è posizionato nella cartella di installazione di symfony in `sfConfig::get('sf_symfony_lib_dir')/config/config/`) e non figura nella cartella di configurazione delle tue applicazioni. Tali impostazioni sono default che raramente hanno bisogno di essere modificate, oppure che sono globali a tutti i progetti. Comunque, se tu avessi bisogno di modificarle, crea un file vuoto nella cartella myproject/apps/frontend/config/  e sovrascrivi i parametri che vuoi cambiare. Le impostazioni definite nell'applicazione hanno sempre la precedenza rispetto a quelle definiti nel framework. Di seguito i file di configurazione nella cartella config/  dell'installazione di symfony: 
+Un secondo insieme di file di configurazione è posizionato nella cartella di installazione di symfony in `sfConfig::get('sf_symfony_lib_dir')/config/config/`) e non figura nella cartella di configurazione delle applicazioni. Tali impostazioni raramente hanno bisogno di essere modificate, oppure sono globali a tutti i progetti. Comunque, se si avesse bisogno di modificarle, creare un file vuoto nella cartella `progetto/apps/frontend/config/` e sovrascrivere i parametri da cambiare. Le impostazioni definite nell'applicazione hanno sempre la precedenza rispetto a quelle definite nel framework. Di seguito, i file di configurazione nella cartella `config/` dell'installazione di symfony: 
 
-  * autoload.yml: Questo file contiene le impostazioni della funzione di autoloading. Tale funzione ti esonera dall'includere classi personalizzate se esse si trovano in una cartella specifica. Questa funzione è descritta nel Capitolo 19.
+  * `autoload.yml`: Questo file contiene le impostazioni della funzione di autoloading. Tale funzione ti esonera dall'includere classi personalizzate se esse si trovano in una cartella specifica. Questa funzione è descritta nel Capitolo 19.
   * `core_compile.yml`: Queste sono liste di classi da includere per far partire un'applicazione. Queste classi vengono poi concatenate in un file PHP ottimizzato senza commenti, che velocizzerà l'esecuzione minimizzando le operazioni di accesso (è caricato un solo file invece di quaranta per ogni richiesta). Questo risulta specialmente utile se non utilizzi un acceleratore PHP. Le tecniche di ottimizzazione sono descritte nel Capitolo 18. 
-  * config_handlers.yml: Qui puoi aggiungere o modificare i gestori usati per processare ogni file di configurazione. Il Capitolo 19 fornisce maggiori dettagli in merito.
+  * `config_handlers.yml`: Qui si possono aggiungere o modificare i gestori usati per processare ogni file di configurazione. Il Capitolo 19 fornisce maggiori dettagli in merito.
   
 ### Configurazione del modulo
 
-Per default un modulo non ha una configurazione specifica. Ma, qualora necessario, puoi fare l'override di qualche impostazione del livello applicazione per un dato modulo. Ad esempio, potresti farlo per includere un file JavaScript specifico in tutte le azioni di un modulo. Puoi anche scegliere di aggiungere nuovi parametri esclusivamente per un dato modulo al fine di preservare l'incapsulamento. 
+Per impostazione predefinita, un modulo non ha una configurazione specifica. Ma, qualora necessario, si possono sovrascrivere delle impostazioni a livello di applicazione per un dato modulo. Ad esempio, per includere un file JavaScript specifico in tutte le azioni di un modulo. Si può anche scegliere di aggiungere nuovi parametri esclusivamente per un dato modulo al fine di preservare l'incapsulamento. 
 
-Come puoi immaginare, le impostazioni di un modulo devono essere nella cartella myproject/apps/frontend/modules/mymodule/config/. I file interessati sono i seguenti: 
+Come si può immaginare, le impostazioni di un modulo devono essere nella cartella `progetto/apps/frontend/modules/mymodule/config/`. I file interessati sono i seguenti: 
 
-  * generator.yml: Per i moduli generati secondo una tabella di database (scaffolding e amministrazione), questo file descrive il modo in cui le righe e campi devono essere visualizzati e quali tipi di interazioni sono proposti all'utente (filtri, ordinamenti, pulsanti e cosi' via). Il Capitolo 14 approfondira' l'argomento. 
-  * module.yml: Questo file contiene parametri specifici a un modulo (equivalente a app.yml, ma a livello modulo) e la configurazione dell'azione. Il Capitolo 6 fornisce maggiori dettagli in merito.
-  * security.yml: Questo file permette di impostare restrizioni per le azioni. Qui puoi impostare il fatto che una certa pagina sia visibile solo agli utenti registrati, oppure a un sottoinsieme di utenti con permessi speciali. Il Capitolo 6 fornisce maggiori dettagli in merito. 
-  * view.yml: Questo file contiene le configurazioni delle viste di una o tutte le azioni di un modulo. Permette l'override di view.yml  del livello applicazione, ed è descritto nel Capitolo 7. 
+  * `generator.yml`: Per i moduli generati secondo una tabella di database (scaffolding e amministrazione), questo file descrive il modo in cui le righe e campi devono essere visualizzati e quali tipi di interazioni sono proposti all'utente (filtri, ordinamenti, pulsanti e così via). Il Capitolo 14 approfondirà l'argomento. 
+  * `module.yml`: Questo file contiene parametri specifici per un modulo (equivalente a `app.yml`, ma a livello di modulo) e la configurazione dell'azione. Il Capitolo 6 fornisce maggiori dettagli in merito.
+  * `security.yml`: Questo file permette di impostare restrizioni per le azioni. Qui si può impostare il fatto che una certa pagina sia visibile solo agli utenti registrati, oppure a un sottoinsieme di utenti con permessi speciali. Il Capitolo 6 fornisce maggiori dettagli in merito. 
+  * `view.yml`: Questo file contiene le configurazioni delle viste di una o tutte le azioni di un modulo. Permette di sovrascrivere `view.yml` del livello dell'applicazione ed è descritto nel Capitolo 7. 
 
 La maggior parte dei file di configurazione dei moduli offrono la possibilità di definire parametri per tutte le viste o tutte le azioni di un modulo, oppure per un loro sottoinsieme. 
 
 >**SIDEBAR**
 >Troppi file?
 >
->Ti potresti sentire travolto dal numero di file di configurazione presenti nell'applicazione. Ma ricorda:
+>Ci potrebbe sentire travolti dal numero di file di configurazione presenti nell'applicazione. Ma è bene ricordare:
 >
->La maggior parte delle volte non avrai bisogno di cambiare la configurazione, perché le convenzioni stabilite per default soddisfano i requisiti più comuni. Ogni file di configurazione corrisponde a una particolare funzione e il prossimo capitolo le affronterà dettagliatamente il loro utilizzo una alla volta. Quando ti focalizzi su di un singlo file, puoi capire chiaramente cosa fa e come è organizzato. Per lo sviluppo web professionale, la configurazione di default è spesso non completamente adatta. I file di configurazione permettono di modificare facilmente i meccanismi di symfony senza scrivere codice. Immagina l'ammontare di codice PHP necessario per raggiungere lo stesso livello di controllo. Se tutti parametri fossero all'interno di un unico file, non solo esso sarebbe illeggibile, ma non ci potrebbe nemmeno essere la possibilità di fare override di parametri a divresi livelli (v. la sezione "Configurazione a cascata" più avanti in questo capitolo). 
+>La maggior parte delle volte non si avrò bisogno di cambiare la configurazione, perché le convenzioni prestabilite soddisfano i requisiti più comuni. Ogni file di configurazione corrisponde a una particolare funzione e il prossimo capitolo affronterà dettagliatamente il loro utilizzo una alla volta. Quando ci si focalizza su un singolo file, si può capire chiaramente cosa fa e come è organizzato. Per lo sviluppo web professionale, la configurazione predefinita è spesso non completamente adatta. I file di configurazione permettono di modificare facilmente i meccanismi di symfony senza scrivere codice. Si immagini l'ammontare di codice PHP necessario per raggiungere lo stesso livello di controllo. Se tutti parametri fossero all'interno di un unico file, non solo esso sarebbe illeggibile, ma non ci potrebbe nemmeno essere la possibilità di sovrascrivere parametri a diversi livelli (vedere la sezione "Configurazione a cascata" più avanti in questo capitolo). 
 >
 >Il sistema di configurazione è uno dei punti di forza di symfony, perché lo rende utilizzabile per qualsiasi tipo di applicazione web e non solamente per quelle per le quali era stato pensato inizialmente. 
 
 Ambienti
 --------
 
-Durante lo sviluppo di un'applicazione, avrai probabilmente bisogno di mantenere in parallelo diversi insiemi di configurazioni. Ad esempio avrai bisogno di avere disponibili le impostazioni di connessione al tuo database di test per lo sviluppo e di avere allo stesso tempo quelli reali per la produzione. Per soddisfare tale fabbisogno, symfony offre diversi ambienti. 
+Durante lo sviluppo di un'applicazione, si avrà probabilmente bisogno di mantenere in parallelo diversi insiemi di configurazioni. Ad esempio, occorrerà avere disponibili le impostazioni di connessione al database di test per lo sviluppo e avere allo stesso tempo quelli reali per la produzione. Per soddisfare tale fabbisogno, symfony offre diversi ambienti. 
 
 ### Cosa è un ambiente?
 
-Una applicazione può girare in diversi ambienti. Tali ambienti condividono lo stesso codice PHP (a parte il front controller) ma possono avere configurazioni completamente differenti. Per ogni applicazione, symfony fornisce tre ambienti: produzione (prod), test (test) e sviluppo (dev). Sei inoltre libero di aggiungerne quanti ne vuoi.
+Una applicazione può girare in diversi ambienti. Tali ambienti condividono lo stesso codice PHP (a parte il front controller) ma possono avere configurazioni completamente differenti. Per ogni applicazione, symfony fornisce tre ambienti: produzione (`prod`), test (`test`) e sviluppo (`dev`). Inoltre, se ne possono aggiungere altri.
 
-Quindi, fondamentalmente, ambienti e configurazioni sono sinonimi. Ad esempio, un ambiente `test` metterà nei log sia alert che errori, mentre un `prod` scriverà solo gli errori. La cache è spesso disattivata in ambienti dev, ma attivata in test  e prod. Gli ambienti `dev` e `test` avranno bisogno di dati di test, memorizzati in un database diverso da quello di produzione. Tutti gli ambienti possono convivere sulla stessa macchina, sebbene di solito un server di produzione ospiti esclusivamente un ambiente `prod`. 
+Quindi, fondamentalmente, ambienti e configurazioni sono sinonimi. Ad esempio, un ambiente `test` metterà nei log sia avvisi che errori, mentre un `prod` scriverà solo gli errori. La cache è spesso disattivata in ambienti `dev`, ma attivata in `test`  e `prod`. Gli ambienti `dev` e `test` avranno bisogno di dati di test, memorizzati in un database diverso da quello di produzione. Tutti gli ambienti possono convivere sulla stessa macchina, sebbene di solito un server di produzione ospiti esclusivamente un ambiente `prod`. 
 
-In `dev`, le impostazioni di log e debug sono tutte abilitate, dato che la manutenzione in tale ambiente è più importante delle performance. Al contrario, l'ambiente di produzione è ottimizzato per le performance per default. Una buona regola è quella di navigare sul sito di sviluppo fino a che sei soddisfatto delle funzioni su cui stai lavorando, quindi passare a quello in produzione per verificarne le performance. 
+In `dev`, le impostazioni di log e debug sono tutte abilitate, dato che la manutenzione in tale ambiente è più importante delle prestazioni. Al contrario, l'ambiente di produzione è ottimizzato per le prestazioni. Una buona regola è quella di navigare sul sito di sviluppo fino a che si è soddisfatti delle funzioni su cui si sta lavorando, quindi passare a quello in produzione per verificarne le prestazioni. 
 
-L'ambiente test differisce dagli altri due in modi diversi. Interagirai con questo ambiente esclusivamente tramite la linea di comando per finalità di test funzionali o scripting batch. Conseguentemente, l'ambiente test è simile a quello di produzione ma non vi si accede navigando. Esso simula l'utilizzo di cookie e altri componenti specifici di HTTP.
+L'ambiente `test` differisce dagli altri due in modi diversi. Si interagirà con questo ambiente esclusivamente tramite la linea di comando per finalità di test funzionali o script batch. Conseguentemente, l'ambiente `test` è simile a quello di produzione, ma non vi si accede navigando. Esso simula l'utilizzo di cookie e altri componenti specifici di HTTP.
 
-Per cambiare ambiente nel quale stai navigando l'applicazione, devi semplicemente cambiare il front controller. Sino a ora hai visto solo l'ambiente di sviluppo, dato che le URL utilizzate negli esempi chiamavano sempre il front controller di sviluppo:
+Per cambiare ambiente nel quale si sta navigando l'applicazione, occorre semplicemente cambiare il front controller. Sinora abbiamo visto solo l'ambiente di sviluppo, dato che gli URL utilizzati negli esempi chiamavano sempre il front controller di sviluppo:
 
-    http://localhost/frontend_dev.php/mymodule/index
+    http://localhost/frontend_dev.php/modulo/index
 
-Se vuoi vedere come l'applicazione reagisce in produzione, puoi invece chiamare il front controller per tale ambiente: 
+Se si vuol vedere come l'applicazione reagisce in produzione, si può invece chiamare il front controller per tale ambiente: 
 
-    http://localhost/index.php/mymodule/index
+    http://localhost/index.php/modulo/index
 
-Se il tuo web server ha il mod_rewrite abilitato, puoi anche utilizzare le regole di symfony per il rewriting, definite in web/.htaccess. Esse definiscono il front controller di produzione come esecuzione di default e permettono di chiamare URL come: 
+Se il server web ha `mod_rewrite` abilitato, si possono anche utilizzare le regole di symfony per la riscrittura, definite in `web/.htaccess`. Esse definiscono il front controller di produzione come indice predefinito e permettono di chiamare URL come: 
 
-    http://localhost/mymodule/index
+    http://localhost/modulo/index
 
 >**SIDEBAR**
 >Ambienti e server
 >
 >Non confondere le nozioni di ambiente e server. In symfony, diversi ambienti sono diverse configurazioni e corrispondono a diversi front controller (gli script che gestiscono le richieste). Server diversi corrispondono a diversi nomi a dominio nelle URL. 
 >
->     http://localhost/frontend_dev.php/mymodule/index
+>     http://localhost/frontend_dev.php/modulo/index
 >            _________ _______________
->             server     environment
+>             server     ambiente
 >
 >Normalmente, gli sviluppatori lavorano alle applicazioni su server di sviluppo, scollegati da Internet e dove le configurazioni possono essere cambiate a piacimento. Quando un'applicazione deve essere pubblicata, i suoi file vengono spostati sul server di sviluppo e resi così pubblici. 
 >
->Questo significa che diversi ambienti sono disponibili su ogni server. Ad esempio, potresti avere sulla stessa macchina ambiente di produzione e di sviluppo. Comunque, la maggior parte delle volte, sul server di produzione ci dovrebbe essere esclusivamente l'ambiente di produzione, per evitare che la configurazione del server sia visibile pubblicamente e quindi ponga dei rischi di sicurezza. Per prevenire l'esposizione accidentale dei controller che non siano di produzione, symfony aggiunge un semplice controllo dell'IP, che consente l'accesso solo da localhost. Se vuoi che siano accessibili, puoi rimuovere questo controllo, ma devi considerare i rischi di renderli accessibili a chiunque, poiché un utente malintenzionato potrebbe indovinare la posizione di default di frontend_dev.php e avere accesso a molte informazioni sensibili.
+>Questo significa che diversi ambienti sono disponibili su ogni server. Ad esempio, si potrebbe avere sulla stessa macchina ambiente di produzione e di sviluppo. Comunque, la maggior parte delle volte, sul server di produzione ci dovrebbe essere esclusivamente l'ambiente di produzione, per evitare che la configurazione del server sia visibile pubblicamente e quindi ponga dei rischi di sicurezza. Per prevenire l'esposizione accidentale dei controller che non siano di produzione, symfony aggiunge un semplice controllo dell'IP, che consente l'accesso solo da localhost. Se si vuole che siano accessibili, si può rimuovere questo controllo, ma occorre considerare i rischi di renderli accessibili a chiunque, poiché un utente malintenzionato potrebbe indovinare la posizione di `frontend_dev.php` e avere accesso a molte informazioni sensibili.
 >
->Per aggiungere un ambiente, non hai bisogno di create una cartella o usare la symfony CLI. Crea semplicemente un nuovo front controller e cambia il nome dell'ambiente. Questo ambiente erediterà tutte le configurazioni di default più i parametri comuni a tutti gli ambienti. Il prossimo capitolo ti insegnerà come farlo. 
+>Per aggiungere un ambiente, non serve creare una cartella o usare la linea di comando di symfony. Creare semplicemente un nuovo front controller e cambiare il nome dell'ambiente. Questo ambiente erediterà tutte le configurazioni predefinite, più i parametri comuni a tutti gli ambienti. Il prossimo capitolo spiegherà come farlo. 
 
 ### Configurazione a cascata
 
-Le stesse impostazioni possono essere definite più di una volta, in posti diversi. Ad esempio, potresti volere impostare il mime-type delle tue pagine come `text/html` per tutte le applicazioni tranne per le pagine di un modulo `rss`, che dovrebbe invece avere un mime-type `text/xml`. Symfony ti da la possibilità di scrivere la prima impostazione in `frontend/config/view.yml` e il secondo in `frontend/modules/rss/config/view.yml`. Il sistema di configurazione sa che un'impostazione definita a livello modulo ha la precedenza rispetto alla stessa definito a livello applicazione.
+Le stesse impostazioni possono essere definite più di una volta, in posti diversi. Ad esempio, si potrebbe volere impostare il tipo mime delle pagine come `text/html` per tutte le applicazioni, tranne per le pagine di un modulo `rss`, che dovrebbe invece avere un tipo mime `text/xml`. Symfony dà la possibilità di scrivere la prima impostazione in `frontend/config/view.yml` e la seconda in `frontend/modules/rss/config/view.yml`. Il sistema di configurazione sa che un'impostazione definita a livello di modulo ha la precedenza rispetto alla stessa definita a livello di applicazione.
 
 Infatti, ci sono diversi livelli di configurazione in symfony:
 
   * Livelli di granularità:
-    * Configurazione di default situata nel framework
-    * Configurazione globale per l'intero progetto (in `myproject/config/`)
-    * Configurazione locale per un'applicazione del progetto (in `myproject/apps/frontend/config/`)
-    * Configurazione ristretta a un modulo (in `myproject/apps/frontend/modules/mymodule/config/`)
+    * Configurazione predefinita del framework
+    * Configurazione globale per l'intero progetto (in `progetto/config/`)
+    * Configurazione locale per un'applicazione del progetto (in `progetto/apps/frontend/config/`)
+    * Configurazione ristretta a un modulo (in `progetto/apps/frontend/modules/modulo/config/`)
   * Livelli ambiente:
-    * Specifico a un ambiente
+    * Specifico per un ambiente
     * Per tutti gli ambienti
 
 Di tutte le proprietà che possono essere personalizzate, diverse sono dipendenti dall'ambiente. Conseguentemente, diversi file di configurazione YAML sono divisi per ambiente, più una sezione di coda per tutti gli ambienti. Il risultato di una tipica configurazione symfony è mostrato nel Listato 5-12.
 
 Listato 5-12 - Struttura dei file di configurazione di symfony 
 
+    [yml]
     # impostazioni per l'ambiente di produzione
     prod:
       ...
@@ -378,50 +379,53 @@ Listato 5-12 - Struttura dei file di configurazione di symfony
     all:
       ...
 
-In più, il framework stesso definisce dei valori di default in file che non sono situati nell'albero del progetto, bensì nella cartella `sfConfig::get('sf_symfony_lib_dir')/config/config/` dell'installazione di symfony. Questa configurazione è mostrata nel Listato 5-13 e tali impostazioni sono ereditate da tutte le applicazioni. 
+In più, il framework stesso definisce dei valori predefinite in file che non sono situati nell'albero del progetto, bensì nella cartella `sfConfig::get('sf_symfony_lib_dir')/config/config/` dell'installazione di symfony. Questa configurazione è mostrata nel Listato 5-13 e tali impostazioni sono ereditate da tutte le applicazioni. 
 
-Listato 5-13 - La configurazione di default, in `sfConfig::get('sf_symfony_lib_dir')/config/config/settings.yml`
+Listato 5-13 - La configurazione predefinita, in `sfConfig::get('sf_symfony_lib_dir')/config/config/settings.yml`
 
+    [yml]
      # Default settings:
      default:
       .actions:
          default_module:        default
-         default_action:         index
+         default_action:        index
          ...
 
-Queste configurazione di default sono ripetute nei file di configurazione di progetti, applicazione e moduli come commenti, come mostrato nel Listato 5-14, così che tu possa conoscere quali sono i parametri di default e modificarli. 
+Queste configurazioni predefinite sono ripetute nei file di configurazione di progetti, applicazioni e moduli come commenti, come mostrato nel Listato 5-14, così che si possa conoscere quali sono i parametri predefiniti e modificarli. 
 
-Listato 5-14 - Configurazione di default, ripetuta per informazione, in frontend/config/settings.yml
+Listato 5-14 - Configurazione predefinita, ripetuta per informazione, in frontend/config/settings.yml
 
+    [yml]
     #all:
     #  .actions:
     #    default_module:         default
     #    default_action:         index
     #    ...
 
-Ciò significa che una proprietà può essere definita diverse volte e l'effettivo valore è il risultato di una cascata di definizioni. Il valore di un parametro definito in un ambiente specifico ha la precedenza sullo stesso valore definito per tutti gli ambienti, che a sua volta ha la precedenza su quello definito per default. Un parametro definito a livello modulo ha la precedenza sullo stesso definito a livello applicazione, che a sua volta ha la precedenza su quello definito a livello progetto. Tutto ciò è mostrato nella seguente lista di priorità: 
+Ciò significa che una proprietà può essere definita diverse volte e l'effettivo valore è il risultato di una cascata di definizioni. Il valore di un parametro definito in un ambiente specifico ha la precedenza sullo stesso valore definito per tutti gli ambienti, che a sua volta ha la precedenza su quello predefinito. Un parametro definito a livello di modulo ha la precedenza sullo stesso definito a livello di applicazione, che a sua volta ha la precedenza su quello definito a livello di progetto. Tutto ciò è mostrato nella seguente lista di priorità: 
 
   1. Modulo
   2. Applicazione
   3. Progetto
   4. Ambiente specifico
   5. Tutti gli ambienti
-  6. Default
+  6. Predefinito
 
 La cache di configurazione
 --------------------------
 
-Fare il parsing di file YAML e avere a che fare con la cascata di configurazioni comporta un grande carico di lavoro per ogni richiesta. Symfony possiede un meccanismo di cache integrato pensato per accelerare le richieste. 
+Analizzare i file YAML e avere a che fare con la cascata di configurazioni comporta un grande carico di lavoro per ogni richiesta. Symfony possiede un meccanismo di cache integrato pensato per accelerare le richieste. 
 
-I file di configurazione, in qualsiasi formato, vengono processati da classi speciali, chiamate gestori, che li trasformano in codice PHP processati velocemente. Nell'ambiente di sviluppo, i gestori controllano se ci sono stati cambiamenti nella configurazione a ogni richiesta, per promuovere l'interattività. Essi fanno il parsing dei file modificati di recente in modo che tu possa vedere un cambiamento in un file YAML immediatamente. Ma nell'ambiente di produzione, questo avviene solo alla prima richiesta, dopodiché il codice PHP processato viene memorizzato in cache per le richieste successive. Le performance sono garantite, dato che ogni richiesta non farà altro che eseguire codice PHP ottimizzato.
+I file di configurazione, in qualsiasi formato, vengono processati da classi speciali, chiamate gestori, che li trasformano in codice PHP processati velocemente. Nell'ambiente di sviluppo, i gestori controllano se ci siano stati cambiamenti nella configurazione a ogni richiesta, per promuovere l'interattività. Essi analizzano i file modificati di recente in modo che si possa vedere un cambiamento in un file YAML immediatamente. Ma nell'ambiente di produzione, questo avviene solo alla prima richiesta, dopodiché il codice PHP processato viene memorizzato in cache per le richieste successive. Le prestazioni sono garantite, dato che ogni richiesta non farà altro che eseguire codice PHP ottimizzato.
 
-Ad esempio, se il file app.yml contenesse:
+Ad esempio, se il file `app.yml` contenesse:
 
+    [yml]
     all:                   # impostazioni per tutti gli ambienti
       mail:
         webmaster:         webmaster@example.com
 
-allora il file config_app.yml.php, situato nella cartella cache/  del tuo progetto, conterrebbe: 
+allora il file `config_app.yml.php`, situato nella cartella `cache/` del progetto, conterrebbe: 
 
     [php]
     <?php
@@ -430,20 +434,20 @@ allora il file config_app.yml.php, situato nella cartella cache/  del tuo proget
       'app_mail_webmaster' => 'webmaster@example.com',
     ));
 
-Come conseguenza, il più delle volte, il framework non fa nemmeno il parsing dei file YAML, ma utilizza solo la cache. In ogni caso, in ambiente di sviluppo, symfony controllerà sistematicamente le date dei file YAML e dei file in cache, riprocessando solo il file che sono stati modificati dall'ultima richiesta.
+Come conseguenza, il più delle volte, il framework non analizza nemmeno i file YAML, ma utilizza solo la cache. In ogni caso, in ambiente di sviluppo, symfony controllerà sistematicamente le date dei file YAML e dei file in cache, riprocessando solo i file che sono stati modificati dall'ultima richiesta.
 
-Questo rappresenta un grande vantaggio rispetto a molti framework PHP, che invece fanno il parsing dei file di configurazione a ogni richiesta, anche in produzione. Diversamente da Java, PHP non condivide un contesto di esecuzione fra le richieste. Per altri framework PHP, possedere la flessibilità di file XML significa colpire le performance, per poter fare il parsing della configurazione a ogni richiesta. Questo non è il caso di symfony. Grazie al sistema di cache, il sovraccarico dovuto alla configurazione è molto basso.
+Questo rappresenta un grande vantaggio rispetto a molti framework PHP, che invece analizzano i file di configurazione a ogni richiesta, anche in produzione. Diversamente da Java, PHP non condivide un contesto di esecuzione fra le richieste. Per altri framework PHP, possedere la flessibilità di file XML significa colpire le prestazioni, per poter analizzare la configurazione a ogni richiesta. Questo non è il caso di symfony. Grazie al sistema di cache, il sovraccarico dovuto alla configurazione è molto basso.
 
-C'è un'importante conseguenza di questo meccanismo. Se cambi la configurazione in produzione, devi forzare il sistema a rileggere i file per poter vedere le tue modifiche. Per poter fare questo, basta pulire la cache, rimuovendo tutti i file dalla cartella cache/ oppure richiamando il comando:
+C'è un'importante conseguenza di questo meccanismo. Se si cambia la configurazione in produzione, occorre forzare il sistema a rileggere i file per poter vedere le modifiche. Per poter fare questo, basta pulire la cache, rimuovendo tutti i file dalla cartella `cache/` oppure richiamando il comando:
 
     $ php symfony cache:clear
 
 Accedere alla configurazione dal codice
 ---------------------------------------
 
-Tutti i file di configurazione sono alla fine trasformati in PHP e molte delle impostazioni che contengono sono utilizzate dal framework senza ulteriori interventi. Comunque, ti potrebbe capitare di dover accedere ad alcune impostazioni direttamente dal tuo codice (in azioni, template, classi e così via). Le impostazioni definite in settings.yml, app.yml e module.yml sono disponibili attraverso una classe speciale chiamata sfConfig. 
+Tutti i file di configurazione sono alla fine trasformati in PHP e molte delle impostazioni che contengono sono utilizzate dal framework senza ulteriori interventi. Comunque, potrebbe capitare di dover accedere ad alcune impostazioni direttamente dal codice (in azioni, template, classi e così via). Le impostazioni definite in `settings.yml`, `app.yml` e `module.yml` sono disponibili attraverso una classe speciale chiamata `sfConfig`. 
 
-### la classe sfConfig
+### La classe `sfConfig`
 
 Si tratta di un registro dei parametri di configurazione, con un semplice metodo getter utilizzabile da qualunque parte dell'applicazione:
 
@@ -451,7 +455,7 @@ Si tratta di un registro dei parametri di configurazione, con un semplice metodo
     // Recuperare un'impostazione
     $parameter = sfConfig::get('param_name', $default_value);
 
-Inoltre è anche possibile definire, o sovrascrivere, di un parametro:
+Inoltre è anche possibile definire, o sovrascrivere, un parametro:
 
     [php]
     // Definire un'impostazione
@@ -463,12 +467,13 @@ Il nome del parametro è una concatenazione di diversi elementi, separati da un
   * La chiave del genitore, se definita, in minuscolo 
   * Il nome della chiave, in minuscolo 
 
-L'ambiente non è incluso, dato che il tuo codice PHP avrà accesso unicamente ai valori definiti per l'ambiente in cui è eseguito.
+L'ambiente non è incluso, dato che il codice PHP avrà accesso unicamente ai valori definiti per l'ambiente in cui è eseguito.
 
-Ad esempio, se tu avessi bisogno di accedere ai parametri definiti in app.yml  mostrato nel Listato 5-15, avrai bisogno del codice mostrato nel Listato 5-16.
+Ad esempio, se si avesse bisogno di accedere ai parametri definiti in `app.yml` mostrato nel Listato 5-15, occorrerà il codice mostrato nel Listato 5-16.
 
-Listato 5-15 - Un esempio di configurazione di app.yml
+Listato 5-15 - Un esempio di configurazione di `app.yml`
 
+    [yml]
     all:
       .general:
         tax:          19.6
@@ -496,17 +501,18 @@ Listato 5-16 - Accedere alle impostazioni di configurazione di PHP nell'ambiente
 
 In tal maniera, le impostazioni di configurazione di symfony hanno tutti i vantaggi delle costanti di PHP, ma non gli svantaggi, in quanto i loro valori possono essere modificati.
 
-Tenendo a mente questo concetto, il file settings.yml, nel quale puoi impostare i parametri del framework per l'applicazione, è equivalente a una lista di chiamate sfConfig::set(). Il Listato 5-17 è interpretato come nel Listato 5-18.
+Tenendo a mente questo concetto, il file `settings.yml`, nel quale si possono impostare i parametri del framework per l'applicazione, è equivalente a una lista di chiamate `sfConfig::set()`. Il Listato 5-17 è interpretato come nel Listato 5-18.
 
 Listato 5-17 - Estratto di `settings.yml`
 
+    [yml]
     all:
       .settings:
         csrf_secret:       FooBar
         escaping_strategy: true
         escaping_method:   ESC_SPECIALCHARS
 
-Listato 5-18 - Ciò che symfony produce quando fa il parsing di settings.yml
+Listato 5-18 - Ciò che symfony produce quando analizza `settings.yml`
 
     [php]
     sfConfig::add(array(
@@ -515,14 +521,15 @@ Listato 5-18 - Ciò che symfony produce quando fa il parsing di settings.yml
       'sf_escaping_method' => 'ESC_SPECIALCHARS',
     ));
 
-Il significato dei parametri del file settings.yml è spiegato nel Capitolo 19.
+Il significato dei parametri del file `settings.yml` è spiegato nel Capitolo 19.
 
-### Impostazioni dell'applicazione personalizzati e app.yml
+### Impostazioni dell'applicazione personalizzati e `app.yml`
 
-La maggior parte delle impostazioni delle funzioni di un'applicazione dovrebbero essere definiti in app.yml, dentro la cartella myproject/apps/frontend/config/. Questo file dipende dall'ambiente e di default vuoto. Imposta in questo file tutti i parametri che vuoi cambiare facilmente e usa la classe sfConfig  per accedere a tali parametri dal tuo codice. Il Listato 5-19 mostra un esempio.
+La maggior parte delle impostazioni delle funzioni di un'applicazione dovrebbero essere definiti in `app.yml`, dentro la cartella `progetto/apps/frontend/config/`. Questo file dipende dall'ambiente e di base è vuoto. Impostare in questo file tutti i parametri che si vogliono cambiare facilmente e usare la classe `sfConfig` per accedere a tali parametri dal codice. Il Listato 5-19 mostra un esempio.
 
 Listato 5-19 - Un esempio di app.yml per definire operazioni su carta di credito 
-
+    
+    [yml]
     all:
       creditcards:
         fake:             false
@@ -533,14 +540,15 @@ Listato 5-19 - Un esempio di app.yml per definire operazioni su carta di credito
       creditcards:
         fake:             true
 
-Per sapere se una carta di credito è accettata nell'ambiente corrente, controlla il valore di: 
+Per sapere se una carta di credito è accettata nell'ambiente corrente, controllare il valore di: 
 
     [php]
     sfConfig::get('app_creditcards_fake');
 
 >**NOTE**
->Quando devi richiedere un array PHP direttamente sotto la chiave `all`, devi usare un header di categoria, altrimenti symfony renderà disponibili i valori separatamente come mostrato sopra.
+>Quando occorre richiedere un array PHP direttamente sotto la chiave `all`, occorre usare un header di categoria, altrimenti symfony renderà disponibili i valori separatamente come mostrato sopra.
 >
+>    [yml]
 >     all:
 >       .array:
 >         creditcards:
@@ -557,22 +565,25 @@ Per sapere se una carta di credito è accettata nell'ambiente corrente, controll
 >       [americanexpress] => true
 >     )
 
+--
+
 >**TIP**
->Ogni qualvolta sei tentato di definire una costante od un parametro nei tuoi script, pensa se non possa essere meglio metterlo nel file `app.yml`. È un posto molto conveniente per memorizzare i parametri dell'applicazione.
+>Ogni qualvolta si è tentati di definire una costante o un parametro in uno script, considerare se non possa essere meglio metterlo nel file `app.yml`. È un posto molto conveniente per memorizzare i parametri dell'applicazione.
 
-Quando hai bisogno di parametri personalizzati e diventa difficile utilizzare la sintassi di `app.yml`, puoi definire una tua sintassi personalizzata. In questo caso, puoi memorizzare la configurazione in un nuovo file, interpretato da un nuovo gestore. Il Capitolo 19 fornisce maggiori informazioni sui gestori di configurazione. 
+Quando servono parametri personalizzati e diventa difficile utilizzare la sintassi di `app.yml`, si può definire una propria sintassi personalizzata. In questo caso, si può memorizzare la configurazione in un nuovo file, interpretato da un nuovo gestore. Il Capitolo 19 fornisce maggiori informazioni sui gestori di configurazione. 
 
 Suggerimenti per ottenere di più dai file di configurazione
 -----------------------------------------------------------
 
-C'è qualche trucco ancora da imparare prima di scrivere i tuoi file YAML. Ti servirà per evitare duplicazione della configurazione e per gestire i tuoi file YAML.
+C'è qualche trucco ancora da imparare prima di scrivere dei file YAML. Servirà per evitare duplicazione della configurazione e per gestire i file YAML.
 
 ### Utilizzare costanti nei file YAML
 
-Certi parametri di configurazione si basano sul valore di altri. Per evitare di duplicare i valori, symfony supporta le costanti in YAML. Quando il gestore della configurazione incontra un parametro (accessibile tramite tramite `sfConfig::get()`) in maiuscolo e racchiuso tra %, esso lo sostituisce con il suo valore effettivo. Il Listato 5-20 ne mostra un esempio.
+Certi parametri di configurazione si basano sul valore di altri. Per evitare di duplicare i valori, symfony supporta le costanti in YAML. Quando il gestore della configurazione incontra un parametro (accessibile tramite tramite `sfConfig::get()`) in maiuscolo e racchiuso tra simboli `%`, esso lo sostituisce con il suo valore effettivo. Il Listato 5-20 ne mostra un esempio.
 
 Listato 5-20 - Utilizzo delle costanti in YAML, esempio da `autoload.yml`
 
+    [yml]
     autoload:
       symfony:
         name:           symfony
@@ -580,37 +591,40 @@ Listato 5-20 - Utilizzo delle costanti in YAML, esempio da `autoload.yml`
         recursive:      on
         exclude:        [vendor]
 
-Il parametro `path` verrà sostituito con il valore di `sfConfig::get('sf_symfony_lib_dir')`. Se vuoi che un file di configurazione si basi su di un altro, devi essere certo che quello su cui si basa venga parsato per primo (controlla i sorgenti di symfony per verificare l'ordine in cui i file di configurazione vengono parsati). `app.yml` è uno degli ultimi file di cui viene fatto il parsing, per cui si può basare su altri.
+Il parametro `path` verrà sostituito con il valore di `sfConfig::get('sf_symfony_lib_dir')`. Se si vuole che un file di configurazione si basi su di un altro, occorre essere certi che quello su cui si basa venga analizzato per primo (controllare i sorgenti di symfony per verificare l'ordine in cui i file di configurazione vengono analizzati). `app.yml` è uno degli ultimi file a essere analizzato, per cui si può basare su altri.
 
-Tutte le costanti disponibili sono descritte in  [symfony reference book](http://www.symfony-project.org/reference/1_4/en/).
+Tutte le costanti disponibili sono descritte nella [guida di riferimento a symfony](http://www.symfony-project.org/reference/1_4/it/).
 
 ### Utilizzare codice nella configurazione
 
-Potrebbe succedere che la tua configurazione si debba basare su parametri esterni (database od un altro file di configurazione). Per gestire questi casi particolari, viene fatto il parsing dei file di configurazione di symfony da PHP prima che essi vengano passi al parser YAML. Questo significa che i file YAML possono contenere codice PHP, come mostrato nel Listato 5-21.
+Potrebbe succedere che la propria configurazione si debba basare su parametri esterni (database o un altro file di configurazione). Per gestire questi casi particolari, viene analizzato il file di configurazione di symfony da PHP prima che essi vengano passati al parser YAML. Questo significa che i file YAML possono contenere codice PHP, come mostrato nel Listato 5-21.
 
 Listato 5-21 - I file YAML possono contenere codice PHP
 
+    [yml]
     all:
       translation:
         format: <?php echo (sfConfig::get('sf_i18n') === true ? 'xliff' : null)."\n" ?>
 
-Ma fai attenzione al fatto che il parsing di questi file viene eseguito molto presto durante il ciclo di vita di una richiesta, per cui non avrai a tua disposizione i metodi o funzioni di symfony.
+Ma fai attenzione al fatto che l'analisi di questi file viene eseguita molto presto durante il ciclo di vita di una richiesta, per cui non si avranno a disposizione i metodi o le funzioni di symfony.
 
-Inoltre, siccome il costrutto `echo` non aggiunge un ritorno a capo di default, è necessario aggiungere un "\n" oppure utilizzare l'helper `echoln` per mantenere valido il formato YAML.
+Inoltre, siccome il costrutto `echo` non aggiunge un ritorno a capo, è necessario aggiungere un "\n" oppure utilizzare l'helper `echoln` per mantenere valido il formato YAML.
 
+    [yml]
     all:
       translation:
         format:  <?php echoln(sfConfig::get('sf_i18n') == true ? 'xliff' : 'none') ?>
 
 >**CAUTION**
->Nell'ambiente di produzione la configurazione è in cache, per cui il parsing (e l'esecuzione) dei file di configurazione avviene esclusivamente dopo che la cache è stata pulita.
+>Nell'ambiente di produzione la configurazione è in cache, per cui l'analisi (e l'esecuzione) dei file di configurazione avviene esclusivamente dopo che la cache è stata pulita.
 
-### Navigare i tuoi file YAML personali
+### Navigare i propri file YAML personali
 
-Ogni qualvolta tu voglia leggere un file YAML direttamente, puoi usare la classe `sfYaml`. Si tratta di un parser YAML che ne trasforma i file in array associativi di PHP. Il Listato 5-22 presenta un file YAML di esempio, mentre il Listato 5-23 mostra come farne il parsing.
+Ogni qualvolta si voglia leggere un file YAML direttamente, si può usare la classe `sfYaml`. Si tratta di un parser YAML che trasforma i file in array associativi di PHP. Il Listato 5-22 presenta un file YAML di esempio, mentre il Listato 5-23 mostra come analizzarlo.
 
 Listato 5-22 - File di esempio `test.yml`
 
+    [yml]
     house:
       family:
         name:     Doe
@@ -656,4 +670,5 @@ Riepilogo
 
 Il sistema di configurazione di symfony utilizza il linguaggio YAML per poter essere semplice e leggibile. La capacità di gestire ambienti multipli e di definire insiemi di parametri tramite cascata offre grande versatilità allo sviluppatore. Alcuni dei parametri sono accessibili via codice tramite l'oggetto `sfConfig`, specialmente quelli specifici dell'applicazione memorizzati nel file `app.yml`.
 
-È vero, symfony ha molti file di configurazione, ma questo approccio lo rende molto adattabile. Ricorda che non hai bisogno di annoiarti con essi se non hai bisogno di un alto livello di personalizzazione.
+È vero, symfony ha molti file di configurazione, ma questo approccio lo rende molto adattabile. Ricordare che non occorre annoiarsi con essi se non occorre un alto livello di personalizzazione.
+

From 1e0c8ceae48af506989147b47b9d87cd4275145c Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Sun, 22 Aug 2010 17:58:52 +0200
Subject: [PATCH 03/10] small fix in license

---
 gentle-introduction/en/B-License.markdown |  2 +-
 gentle-introduction/it/B-License.markdown | 31 ++++++++++++-----------
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/gentle-introduction/en/B-License.markdown b/gentle-introduction/en/B-License.markdown
index cb8ae8b..5489c49 100644
--- a/gentle-introduction/en/B-License.markdown
+++ b/gentle-introduction/en/B-License.markdown
@@ -128,6 +128,6 @@ You may not copy, modify, sublicense, or distribute the Document except as expre
 10. FUTURE REVISIONS OF THIS LICENSE
 ------------------------------------
 
-The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See `http://www.gnu. org/copyleft/`. 
+The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See <http://www.gnu.org/copyleft/>. 
 
 Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. 
diff --git a/gentle-introduction/it/B-License.markdown b/gentle-introduction/it/B-License.markdown
index 8c1c812..f69a112 100644
--- a/gentle-introduction/it/B-License.markdown
+++ b/gentle-introduction/it/B-License.markdown
@@ -226,35 +226,36 @@ questa stessa licenza, con la versione modificata che svolga il
 ruolo del "documento", così da estendere la licenza sulla
 distribuzione e la modifica a chiunque ne possieda una copia.
 Inoltre nelle versioni modificate si deve:
-A. Usare nella pagina del titolo (e nelle copertine se ce ne
+
+* Usare nella pagina del titolo (e nelle copertine se ce ne
 sono) un titolo diverso da quello del documento, e da
 quelli di versioni precedenti (che devono essere elencati
 nella sezione storia del documento ove presenti). Si può
 usare lo stesso titolo di una versione precedente se
 l'editore di quella versione originale ne ha dato il
 permesso.
-B. Elencare nella pagina del titolo, come autori, una o più
+* Elencare nella pagina del titolo, come autori, una o più
 persone o gruppi responsabili in qualità di autori delle
 modifiche nella versione modificata, insieme ad almeno
 cinque fra i principali autori del documento (tutti gli
 autori principali se sono meno di cinque), a meno che
 questi non abbiano acconsentito a liberarvi da
 quest'obbligo.
-C. Dichiarare nella pagina del titolo il nome dell'editore
+* Dichiarare nella pagina del titolo il nome dell'editore
 della versione modificata in qualità di editore.
 D. Conservare tutte le note di copyright del documento
 originale.
-E. Aggiungere un'appropriata nota di copyright per le
+* Aggiungere un'appropriata nota di copyright per le
 modifiche di seguito alle altre note di copyright.
-F. Includere, immediatamente dopo la nota di copyright, una
+* Includere, immediatamente dopo la nota di copyright, una
 nota di licenza che dia pubblicamente il permesso di usare
 la versione modificata nei termini di questa licenza, nella
 forma mostrata nell'addendum alla fine di questo testo.
-G. Preservare in tale nota di licenza l'elenco completo di
+* Preservare in tale nota di licenza l'elenco completo di
 sezioni non modificabili e testi di copertina richiesti
 come previsto dalla licenza del documento.
-H. Includere una copia non modificata di questa licenza.
-I. Conservare la sezione intitolata "Storia", e il suo titolo,
+* Includere una copia non modificata di questa licenza.
+* Conservare la sezione intitolata "Storia", e il suo titolo,
 e aggiungere a questa un elemento che riporti almeno il
 titolo, l'anno, i nuovi autori, e gli editori della
 versione modificata come figurano nella pagina del titolo.
@@ -263,7 +264,7 @@ crearne una che riporti il titolo, gli autori, gli editori
 del documento come figurano nella pagina del titolo, quindi
 aggiungere un elemento che descriva la versione modificata
 come detto in precedenza.
-J. Conservare l'indirizzo in rete riportato nel documento, se
+* Conservare l'indirizzo in rete riportato nel documento, se
 c'è, al fine del pubblico accesso a una copia trasparente,
 e possibilmente l'indirizzo in rete per le precedenti
 versioni su cui ci si è basati. Questi possono essere
@@ -271,18 +272,18 @@ collocati nella sezione "Storia". Si può omettere un
 indirizzo di rete per un'opera pubblicata almeno quattro
 anni prima del documento stesso, o se l'originario editore
 della versione cui ci si riferisce ne dà il permesso.
-K. In ogni sezione di "Ringraziamenti" o "Dediche", si
+* In ogni sezione di "Ringraziamenti" o "Dediche", si
 conservino il titolo, il senso, il tono ivi utilizzati.
-L. Si conservino inalterate le sezioni non modificabili del
+* Si conservino inalterate le sezioni non modificabili del
 documento, nei propri testi e nei propri titoli. I numeri
 della sezione o equivalenti non sono considerati parte del
 titolo della sezione.
-M. Si cancelli ogni sezione intitolata "Approvazioni". Tale
+* Si cancelli ogni sezione intitolata "Approvazioni". Tale
 sezione non può essere inclusa nella versione modificata.
-N. Non si cambi il titolo di sezioni esistenti in
+* Non si cambi il titolo di sezioni esistenti in
 "Approvazioni" o in modo tale che si possa creare
 confusione con i titoli di sezioni non modificabili.
-O. Si conservino tutti i limiti alla garanzia.
+* Si conservino tutti i limiti alla garanzia.
 
 Se la versione modificata comprende nuove sezioni di primaria
 importanza o appendici che ricadono in "sezioni secondarie", e
@@ -449,7 +450,7 @@ versioni nuove o rivedute della Licenza per Documentazione
 Libera GNU. Le nuove versioni saranno simili nello spirito alla
 versione attuale ma potrebbero differirne in qualche dettaglio
 per affrontare nuovi problemi e concetti. Si veda
-http://www.gnu.org/copyleft/ .
+<http://www.gnu.org/copyleft/>.
 
 Ad ogni versione della licenza viene dato un numero che la
 distingue. Se il documento specifica che si riferisce a una

From 341143501b721b9deea356aa2f5178bc0263f704 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Sat, 28 Aug 2010 09:17:12 +0200
Subject: [PATCH 04/10] [gentle][it] minor fixes

---
 .../it/01-Introducing-Symfony.markdown        |  2 +-
 .../it/03-Running-Symfony.markdown            |  6 ++--
 .../06-Inside-the-Controller-Layer.markdown   | 16 ++++-----
 .../it/07-Inside-the-View-Layer.markdown      | 14 ++++----
 ...8-Inside-the-Model-Layer-Doctrine.markdown | 28 +++++++--------
 gentle-introduction/it/10-Forms.markdown      |  4 +--
 .../16-Application-Management-Tools.markdown  |  2 +-
 .../it/17-Extending-Symfony.markdown          | 21 ++++++------
 .../A-Inside-the-Model-Layer-Propel.markdown  | 34 +++++++++----------
 9 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/gentle-introduction/it/01-Introducing-Symfony.markdown b/gentle-introduction/it/01-Introducing-Symfony.markdown
index 4598f40..2a4d432 100644
--- a/gentle-introduction/it/01-Introducing-Symfony.markdown
+++ b/gentle-introduction/it/01-Introducing-Symfony.markdown
@@ -50,7 +50,7 @@ Symfony è stato creato per soddisfare i seguenti requisiti:
 La maggior parte delle caratteristiche comuni dei progetti web sono automatizzate in
 symfony, come segue:
 
-  * Lo strato precostituito di internazionalizzazione consente la traduzione sia dei dati
+  * Il livello di internazionalizzazione consente la traduzione sia dei dati
     che delle interfacce, così come anche localizzazione dei contenuti.
   * La presentazione usa template e layout che possono essere costruiti da grafici HTML
     senza alcuna conoscenza del framework. Le funzioni helper riducono l'ammontare di
diff --git a/gentle-introduction/it/03-Running-Symfony.markdown b/gentle-introduction/it/03-Running-Symfony.markdown
index eb924ae..b10fbc0 100644
--- a/gentle-introduction/it/03-Running-Symfony.markdown
+++ b/gentle-introduction/it/03-Running-Symfony.markdown
@@ -314,17 +314,17 @@ cartella `apps/frontend/`.
 >due vulnerabilità più diffuse sul web. Symfony
 >attua automaticamente le misure di ~sicurezza|Sicurezza~ per nostro conto.
 >
->Per prevenire attacchi di tipo ~XSS~, viene abilitata l'escapizzazione dell'output; per prevenire
+>Per prevenire attacchi di tipo ~XSS~, viene abilitata l'escape dell'output; per prevenire
 >attacchi di tipo ~CSRF~, viene generata una stringa CSRF casuale.
 >
 >Naturalmente, queste impostazioni si possono modificare, grazie alle *opzioni* seguenti:
 >
->  * `--escaping-strategy`: Abilita o disabilita l'escapizzazione dell'output
+>  * `--escaping-strategy`: Abilita o disabilita l'escape dell'output
 >  * `--csrf-secret`: Abilita i token di sessione nei form
 >
 >Per chi ne sa poco di
 >[XSS](http://en.wikipedia.org/wiki/Cross-site_scripting) o
->[CSRF](http://en.wikipedia.org/wiki/CSRF), è meglio dedicare un po' di tempo per imparare qualcosa
+>[CSRF](http://en.wikipedia.org/wiki/CSRF), è meglio dedicare un po' di tempo a imparare qualcosa
 >su queste vulnerabilità relative alla sicurezza.
 
 ### Permessi nella struttura delle cartelle
diff --git a/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown b/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
index be08f6c..f86f0c2 100644
--- a/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
+++ b/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
@@ -1,11 +1,11 @@
-Capitolo 6 - All'interno dello strato controllore
-=================================================
+Capitolo 6 - All'interno del livello del controllore
+====================================================
 
-Il controllore in symfony è lo strato che contiene il codice che collega la business logic alla presentazione, esso è diviso in diversi componenti che si usano per diversi scopi:
+Il controllore in symfony è il livello che contiene il codice che collega la business logic alla presentazione, diviso in diversi componenti che si usano per diversi scopi:
 
   * Il front controller è il punto d'accesso univoco all'applicazione. Si occupa di caricare la configurazione e determina l'azione da eseguire.
-  * Le azioni contengono la logica dell'applicazione. Verificano l'integrità della richiesta e preparano i dati necessari allo strato di presentazione.
-  * Richiesta, risposta e oggetti di sessione permettono l'accesso ai parametri della richiesta, alle intestazioni della risposta e ai dati persistenti dell'utente. Vengono usati molto spesso nello strato controllore.
+  * Le azioni contengono la logica dell'applicazione. Verificano l'integrità della richiesta e preparano i dati necessari al livello della vista.
+  * Richiesta, risposta e oggetti di sessione permettono l'accesso ai parametri della richiesta, alle intestazioni della risposta e ai dati persistenti dell'utente. Vengono usati molto spesso nel livello controllore.
   * I filtri sono porzioni di codice eseguito a ogni richiesta, prima o dopo l'azione. Per esempio i filtri di sicurezza e validazione sono usati comunemente nelle applicazioni web. Si può facilmente estendere il framework creando i propri filtri.
 
 Questo capitolo descrive tutti questi componenti, non fatevi intimidire dal loro numero. Per una pagina semplice molto probabilmente basterà scrivere poche righe di codice nella classe dell'azione, tutto qui. Gli altri componenti del controllore vengono utilizzati solo in situazioni particolari.
@@ -129,7 +129,7 @@ Listing 6-4 - Classe azione con due azioni, in `frontend/modules/mymodule/action
       }
     }
 
-Se la dimensione di una classe azione tende a crescere troppo, molto probabilmente, necessita di un po' di refactoring per spostare del codice verso lo strato del modello. Le azioni dovrebbero essere mantenute sempre brevi (non più di alcune righe), mentre tutta la business logic dovrebbe essere nel modello.
+Se la dimensione di una classe azione tende a crescere troppo, molto probabilmente necessita di un po' di rifattorizzazione per spostare del codice verso il livello del modello. Le azioni dovrebbero essere mantenute sempre brevi (non più di alcune righe), mentre tutta la business logic dovrebbe essere nel modello.
 
 Nonostante questo il numero di azioni in un modulo potrebbe essere così elevato da spingervi a separarlo in due moduli.
 
@@ -267,7 +267,7 @@ Nel caso in cui non esista una vista da chiamare--per esempio nel caso in cui un
     [php]
     return sfView::NONE;
 
-Nessun template verrà eseguito in questo caso. Significa che è possibile aggirare completamente lo strato della vista e impostare il codice HTML di risposta direttamente in un'azione. Come mostrato nel listato 6-9, symfony mette a disposizione uno specifico metodo `renderText()` per questo caso. Può essere utile quando si ha bisogno di un'azione estremamente responsiva, come per le interazioni Ajax, che verranno affrontate nel Capitolo 11.
+Nessun template verrà eseguito in questo caso. Significa che è possibile aggirare completamente il livello della vista e impostare il codice HTML di risposta direttamente in un'azione. Come mostrato nel listato 6-9, symfony mette a disposizione uno specifico metodo `renderText()` per questo caso. Può essere utile quando si ha bisogno di un'azione estremamente responsiva, come per le interazioni Ajax, che verranno affrontate nel Capitolo 11.
 
 Listing 6-9 - Aggirare la vista facendo l'echo della risposta e ritornando `sfView::NONE`
 
@@ -987,6 +987,6 @@ Il parametro `partial_view_class` definisce la classe della vista utilizzata per
 Sommario
 --------
 
-In symfony lo strato del controllore è diviso in due parti: il front controller, l'unico punto d'accesso per l'applicazione in un dato ambiente, e le azioni che contengono la logica delle pagine. Un'azione ha l'abilità di determinare come verrà eseguita la sua vista restituendo una delle costanti `sfView`. All'interno di un'azione si possono manipolare i diversi elementi del context, inclusi l'oggetto della richiesta (`sfRequest`) e l'oggetto della sessione utente corrente (`sfUser`).
+In symfony il livello del controllore è diviso in due parti: il front controller, l'unico punto d'accesso per l'applicazione in un dato ambiente, e le azioni che contengono la logica delle pagine. Un'azione ha l'abilità di determinare come verrà eseguita la sua vista restituendo una delle costanti `sfView`. All'interno di un'azione si possono manipolare i diversi elementi del context, inclusi l'oggetto della richiesta (`sfRequest`) e l'oggetto della sessione utente corrente (`sfUser`).
 
 Combinando assieme la potenza dell'oggetto sessione, l'oggetto azione, le configurazioni di sicurezza, symfony mette a disposizione un completo sistema di sicurezza con restrizione sull'accesso e sistema di credenziali associato. Se i metodi `preExecute()` e `postExecute()` sono stati pensati per il riutilizzo del codice all'interno di un modulo, i filtri permettono lo stesso grado di riutilizzo per tutte le applicazioni facendo eseguire codice del controllore per ogni singola richiesta.
diff --git a/gentle-introduction/it/07-Inside-the-View-Layer.markdown b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
index a5f5e9d..225a86e 100644
--- a/gentle-introduction/it/07-Inside-the-View-Layer.markdown
+++ b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
@@ -1,5 +1,5 @@
-Capitolo 7 - All'interno dello strato vista
-===========================================
+Capitolo 7 - All'interno del livello della vista
+================================================
 
 La vista è la responsabile per la visualizzazione dell'output relativo a una particolare azione. In symfony, la vista è costituita da più parti, di cui ogni singolo elemento è stato progettato per essere facilmente modificato da chi di solito lavora con esso.
 
@@ -553,9 +553,9 @@ Listato 7-19 - Configurazione predefinita della vista a livello di applicazione,
 
 Ciascuna di queste impostazioni verrà descritta in dettaglio nella sezione "Impostazione della configurazione della vista".
 
-### L'oggetto Response
+### L'oggetto response
 
-Sebbene faccia parte dello strato vista, l'oggetto response viene spesso modificato dall'azione. Le azioni possono accedere all'oggetto response di symfony, chiamato `sfResponse`, attraverso il metodo `getResponse()`. Il Listato 7-20 elenca alcuni dei metodi di `sfResponse` spesso utilizzati all'interno di un'azione.
+Sebbene faccia parte del livello vista, l'oggetto response viene spesso modificato dall'azione. Le azioni possono accedere all'oggetto response di symfony, chiamato `sfResponse`, attraverso il metodo `getResponse()`. Il Listato 7-20 elenca alcuni dei metodi di `sfResponse` spesso utilizzati all'interno di un'azione.
 
 Listato 7-20 - Le azioni hanno accesso ai metodi dell'oggetto `sfResponse`
 
@@ -865,8 +865,8 @@ Listato 7-37 - Rimozione del layout
 >**NOTE**
 >Le viste per le azioni Ajax non hanno layout per impostazione predefinita.
 
-Escapizzazione dell'output
---------------------------
+Escape dell'output
+------------------
 
 Quando vengono inseriti dati dinamici in un template, bisogna essere sicuri dell'integrità dei dati. Per esempio, se i dati provengono da form compilati da utenti anonimi, c'è il rischio che possano includere script maligni che hanno lo scopo di lanciare attacchi di tipo cross-site scripting (XSS). Bisogna essere in grado di fare l'escape dei dati visualizzati, in modo che qualunque tag HTML possa contenere diventi inerte.
 
@@ -974,7 +974,7 @@ Listato 7-39 - L'escape funziona anche per gli array e gli oggetti
     <?php echo get_class($test_object) ?>
      => sfOutputEscaperObjectDecorator
 
-Questo spiega perché alcune normali funzioni PHP (come `array_shift()`, `print_r()` e altre) non funzionano più con gli array esacpizzati. Ma questi possono essere acceduti utilizzando `[]`, essere attraversati usando `foreach` e restituire il corretto risultato con `count()`. E in ogni caso nei template i dati dovrebbero essere a sola lettura, quindi la maggior parte degli accessi verrà fatta utilizzando metodi che funzionano correttamente.
+Questo spiega perché alcune normali funzioni PHP (come `array_shift()`, `print_r()` e altre) non funzionano più con gli array sotto escape. Ma questi possono essere acceduti utilizzando `[]`, essere attraversati usando `foreach` e restituire il corretto risultato con `count()`. E in ogni caso nei template i dati dovrebbero essere a sola lettura, quindi la maggior parte degli accessi verrà fatta utilizzando metodi che funzionano correttamente.
 	 
 C'è ancora un modo per recuperare i dati raw attraverso l'oggetto `$sf_data`. Inoltre, i metodi di oggetti sotto escape vengono alterati per accettare un parametro aggiuntivo: un metodo di escape. Così si può scegliere un metodo alternativo per fare l'escape ogni volta che si visualizza una variabile in un template, oppure optare per l'helper `ESC_RAW` per disattivare l'escape. Vedere il Listato 7-40 come esempio.
 
diff --git a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
index 53631d1..88af3c8 100644
--- a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
+++ b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
@@ -1,19 +1,19 @@
-Capitolo 8 - All'interno dello strato modello (Doctrine)
-===========================================
+Capitolo 8 - All'interno del livello del modello (Doctrine)
+===========================================================
 
-Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su uno strato che mappa oggetti e relazioni. Symfony è in bundle con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
+Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su un livello che mappa oggetti e relazioni. Symfony è distribuito con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
 
 Questo capitolo spiega come creare un modello di dati a oggetti e come accedere ai dati e modificarli con Doctrine. Viene anche trattata l'integrazione di Doctrine con symfony.
 
 >**TIP**
 >Se si vuole utilizzare Propel al posto di Doctrine, leggere l'Appendice A che contiene le stesse informazioni ma riferite a Propel.
 
-Perché usare un ORM e uno strato per l'astrazione?
+Perché usare un ORM e un livello per l'astrazione?
 --------------------------------------------------
 
 I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM), ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
 
-Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Lo strato ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
+Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
 
 Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo accessor alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
 
@@ -41,7 +41,7 @@ Listato 8-2 - Il metodo accessor maschera la logica dei dati
       return $totale;
     }
 
-C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo dello strato di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL. 
+C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL. 
 
 Il principale vantaggio del livello di astrazione è la portabilità, perché rende possibile il passaggio a un'altra base di dati, anche nel bel mezzo di un progetto. Si supponga di dover scrivere rapidamente un prototipo per un'applicazione, ma il cliente non ha ancora deciso quale sistema di base dati può essere la più adatto alle sue esigenze. Si può cominciare a costruire l'applicazione con SQLite, per esempio e passare a MySQL, PostgreSQL, Oracle quando il cliente ha fatto la scelta. Per fare il cambiamento, basta cambiare una riga in un file di configurazione. 
 
@@ -120,7 +120,7 @@ I modelli possono anche contenere chiavi esterne esplicite e indici. Per saperne
 Le classi del modello
 ---------------------
 
-Lo schema è usato per costruire le classi del modello nello strato ORM. Per risparmiare tempo di esecuzione, queste classi sono generate con un task a riga di comando chiamato `doctrine:build-model`.
+Lo schema è usato per costruire le classi del modello nel livello ORM. Per risparmiare tempo di esecuzione, queste classi sono generate con un task a riga di comando chiamato `doctrine:build-model`.
 
     $ php symfony doctrine:build-model
 
@@ -321,7 +321,7 @@ Listato 8-12 - Recuperare i record di Doctrine_Query con `createQuery()`--Query
 >**SIDEBAR**
 >Idratazione
 >
->La chiamata a `->execute()` è molto più potente di una semplice query SQL. Primo, l'SQL è ottimizzato per il DBMS che si è scelto. Secondo, ogni valore passato a `Doctrine_Query` è escapizzato prima di essere inserito nel codice SQL, il che previene i rischi di SQL injection. Terzo, il metodo restituisce un array di oggetti, piuttosto che un insieme di risultati. L'ORM crea e popola automaticamente gli oggetti basandosi sull'insieme dei risultati del database. Questo processo è chiamato idratazione.
+>La chiamata a `->execute()` è molto più potente di una semplice query SQL. Primo, l'SQL è ottimizzato per il DBMS che si è scelto. Secondo, ogni valore passato a `Doctrine_Query` è passato sotto escape prima di essere inserito nel codice SQL, il che previene i rischi di SQL injection. Terzo, il metodo restituisce un array di oggetti, piuttosto che un insieme di risultati. L'ORM crea e popola automaticamente gli oggetti basandosi sull'insieme dei risultati del database. Questo processo è chiamato idratazione.
 
 Per selezionare gli oggetti in modo più complesso, è necessario un qualcosa di equivalente a WHERE, ORDER BY, GROUP BY e alle altre istruzioni SQL. L'oggetto `Doctrine_Query` ha metodi e parametri per tutte queste condizioni. Ad esempio, per recuperare tutti i commenti scritti da Fabrizio, ordinati per data, fare una `Doctrine_Query` come mostrato nel Listato 8-13.
 
@@ -407,13 +407,13 @@ Listato 8-15 - Query SQL personalizzate con PDO
 Così come per Doctrine, le query PDO possono sembrare difficili all'inizio. Ancora una volta, gli esempi di applicazioni esistenti e i tutorial, mostreranno il modo più corretto per utilizzarle.
 
 >**CAUTION**
->Se si è tentati di saltare questo processo e accedere direttamente al database, si rischia di perdere la sicurezza e l'astrazione fornite da Doctrine. Farlo con Doctrine è più lungo, ma costringe a usare buone pratiche che garantiscono prestazioni, portabilità e sicurezza per l'applicazione. Ciò è particolarmente vero per le query che contengono parametri provenienti da una fonte non attendibile (ad esempio, un utente Internet). Doctrine fa tutte le necessarie escapizzazioni e protegge i dati. L'accesso al database mette direttamente a rischio di attacchi di tipo SQL injection.
+>Se si è tentati di saltare questo processo e accedere direttamente al database, si rischia di perdere la sicurezza e l'astrazione fornite da Doctrine. Farlo con Doctrine è più lungo, ma costringe a usare buone pratiche che garantiscono prestazioni, portabilità e sicurezza per l'applicazione. Ciò è particolarmente vero per le query che contengono parametri provenienti da una fonte non attendibile (ad esempio, un utente Internet). Doctrine fa tutti i necessari escape e protegge i dati. L'accesso al database mette direttamente a rischio di attacchi di tipo SQL injection.
 
 ### Uso di colonne speciali per le date
 
-Generalmente, quando una tabella ha una colonna chiamata `created_at`, è usata per memorizzare un timestamp della data di creazione di un record. Stessa cosa per le colonne `updated_at` (aggiornato_il), che vengono aggiornate con il valore del tempo corrente, ogni volta che il record stesso viene aggiornato
+Generalmente, quando una tabella ha una colonna chiamata `created_at`, qeusta è usata per memorizzare un timestamp della data di creazione di un record. Stessa cosa per le colonne `updated_at`, che vengono aggiornate con il valore del tempo corrente, ogni volta che il record stesso viene aggiornato
 
-La buona notizia è che Doctrine ha un comportamento `Timestampable` che gestirà questi aggiornamenti per noi. Non è necessario impostare manualmente le colonne `created_at` e `updated_at`; verranno aggiornate automaticamente , come mostrato nel Listato 8-16.
+La buona notizia è che Doctrine ha un comportamento `Timestampable` che gestirà questi aggiornamenti per noi. Non è necessario impostare manualmente le colonne `created_at` e `updated_at`; verranno aggiornate automaticamente, come mostrato nel Listato 8-16.
 
 Listato 8-16 - Le colonne `created_at` e `updated_at` Columns sono gestite automaticamente
 
@@ -427,7 +427,7 @@ Listato 8-16 - Le colonne `created_at` e `updated_at` Columns sono gestite autom
       => [data dell'operazione di INSERT nel database]
 
 >**SIDEBAR**
->Rifattorizzazione nello strato dei dati
+>Rifattorizzazione nel livello dei dati
 >
 >Quando si sviluppa un progetto symfony, spesso si inizia scrivendo il codice della logica di dominio nelle azioni. Ma le query sul database e la manipolazione del modello non devono essere messi nel livello del controllore. Tutta la logica relativa ai dati dovrebbe essere spostata al livello di modello. Ogni volta che si deve fare la stessa richiesta in più di un posto nelle azioni, è meglio pensare di trasferire il relativo codice al modello. Aiuta a mantenere le azioni brevi e leggibili.
 >
@@ -443,7 +443,7 @@ Listato 8-16 - Le colonne `created_at` e `updated_at` Columns sono gestite autom
 >
 >L'azione crea un oggetto  della classe `Tag` dal parametro della request. Tutto il codice necessario per interrogare il database si trova nel metodo `getArticoliPopolari` di questa classe. Rende l'azione più leggibile e il codice del modello può facilmente venire riutilizzato in un'altra azione.
 >
->Spostare il codice in un posto più appropriato è una delle tecniche della rifattorizzazione. Se la si fa spesso, il codice sarà semplice da mantenere e da comprendere da parte di altri sviluppatori. Una buona regola per capire quando fare refactoring nello strato dei dati, è che il codice di una azione raramente deve contenere più di dieci righe di codice PHP.
+>Spostare il codice in un posto più appropriato è una delle tecniche della rifattorizzazione. Se la si fa spesso, il codice sarà semplice da mantenere e da comprendere da parte di altri sviluppatori. Una buona regola per capire quando fare refactoring nel livello dei dati, è che il codice di una azione raramente deve contenere più di dieci righe di codice PHP.
 
 Connessioni al database
 ---------------------------
@@ -844,6 +844,6 @@ Riepilogo
 
 Symfony usa Doctrine come ORM e PHP Data Objects per il livello di astrazione del database. Ciò significa che è necessario prima descrivere lo schema relazionale del database in YAML prima di generare le classi del modello a oggetti. Poi, in fase di runtime, utilizzare i metodi dell'oggetto e le classi delle tabelle per recuperare informazioni su un record o un insieme di record. È possibile facilmente sovrascrivere ed estendere il modello aggiungendo metodi alle classi personalizzate. Le impostazioni di connessione sono definite in un file `databases.yml`, che può supportare più di una connessione. E la linea di comando contiene dei task speciali per evitare di duplicare la definizione della struttura. 
 
-Lo strato del modello è il più complesso del framework symfony. Una delle ragioni di questa complessità è che la manipolazione dei dati è una questione intricata. I problemi di sicurezza correlati sono fondamentali per un sito web e non devono essere ignorati. Un'altra ragione è che symfony è più adatto ad applicazioni di medio-grandi dimensioni in contesto enterprise. In tali applicazioni, le automazioni fornite dal modello di symfony possono davvero rappresentare un guadagno di tempo che vale l'investimento per apprendere il suo funzionamento. 
+Il livello del modello è il più complesso del framework symfony. Una delle ragioni di questa complessità è che la manipolazione dei dati è una questione intricata. I problemi di sicurezza correlati sono fondamentali per un sito web e non devono essere ignorati. Un'altra ragione è che symfony è più adatto ad applicazioni di medio-grandi dimensioni in contesto enterprise. In tali applicazioni, le automazioni fornite dal modello di symfony possono davvero rappresentare un guadagno di tempo che vale l'investimento per apprendere il suo funzionamento. 
 
 Quindi non esitate nel dedicare un periodo di prova al modello a oggetti e ai metodi, per comprenderli pienamente. La solidità e la scalabilità delle applicazioni saranno la ricompensa.
diff --git a/gentle-introduction/it/10-Forms.markdown b/gentle-introduction/it/10-Forms.markdown
index 41b2ecb..9b225ba 100644
--- a/gentle-introduction/it/10-Forms.markdown
+++ b/gentle-introduction/it/10-Forms.markdown
@@ -504,7 +504,7 @@ Gestire le richieste dei form
 
 Quando gli utenti riempiono un form e lo inviano, il server deve recuperare i dati dalla richiesta e fare alcune cose con essi. La classe `sfForm` fornisce tutti i metodi necessari per fare questo in un paio di linee di codice. 
 
-### Gestione semplice dei Form
+### Gestione semplice dei form
 
 Dato che i widget restituiscono dei campi form HTML regolari, ricevere il loro valore nell'azione che tratta l'invio dei form è semplice: basta testare i relativi parametri della richiesta. Per il form di contatto di esempio, l'azione potrebbe essere scritta come segue:
 
@@ -883,7 +883,7 @@ I validatori multipli operano sull'intero form, anziché su un singolo input. Se
 Modi alternativi di usare un form
 ---------------------------------
 
-### Classi Form
+### Classi form
 
 Con tutte le opzioni dei widget, i validatori e i parametri dei form, la definizione del form dei contatti scritta nella classe delle azioni appare piuttosto confusa:
 
diff --git a/gentle-introduction/it/16-Application-Management-Tools.markdown b/gentle-introduction/it/16-Application-Management-Tools.markdown
index 4b1d506..8abbea2 100644
--- a/gentle-introduction/it/16-Application-Management-Tools.markdown
+++ b/gentle-introduction/it/16-Application-Management-Tools.markdown
@@ -440,7 +440,7 @@ Listato 16-14 - Un esempio di task più completo, in `lib/task/mioSecondoTask.cl
     }
 
 >**NOTE**
->Se il task ha bisogno di accedere allo strato database, deve estendere `sfPropelBaseTask` invece di `sfBaseTask`. L'inizializzazione del task si prenderà cura di caricare le classi di Propel. Si può iniziare una connessione al database nel metodo `execute()` chiamando:
+>Se il task ha bisogno di accedere al livello del database, deve estendere `sfPropelBaseTask` invece di `sfBaseTask`. L'inizializzazione del task si prenderà cura di caricare le classi di Propel. Si può aprire una connessione al database nel metodo `execute()` chiamando:
 >
 >    $databaseManager = new sfDatabaseManager($this->configuration);
 >
diff --git a/gentle-introduction/it/17-Extending-Symfony.markdown b/gentle-introduction/it/17-Extending-Symfony.markdown
index 0bc2c63..70affa4 100644
--- a/gentle-introduction/it/17-Extending-Symfony.markdown
+++ b/gentle-introduction/it/17-Extending-Symfony.markdown
@@ -27,7 +27,7 @@ Listato 17-1 - Registrare un ascoltatore di eventi
       // fa qualcosa con la cultura dell'utente
     }
 
-Tutti gli eventi e le registrazioni degli ascoltatori sono gestiti da un oggetto speciale chiamato *dispatcher di eventi*. Questo oggetto è disponibile ovunque in symfony attraverso l'istanza di `ProjectConfiguration` e la maggior parte degli oggetti di symfony offrono un metodo `getEventDispatcher()` per ottenere un accesso diretto ad esso. Utilizzando il metodo `connect()` del dispatcher, è possibile registrare qualsiasi callable PHP (o un metodo di classe o una funzione) da chiamare quando si verifica un evento. Il primo argomento di `connect()` è l'identificatore dell'evento, che è una stringa composta da uno spazio nomi e da un nome. Il secondo argomento è un callable PHP.
+Tutti gli eventi e le registrazioni degli ascoltatori sono gestiti da un oggetto speciale chiamato *dispatcher di eventi*. Questo oggetto è disponibile ovunque in symfony attraverso l'istanza di `ProjectConfiguration` e la maggior parte degli oggetti di symfony offrono un metodo `getEventDispatcher()` per accedervi direttamente. Utilizzando il metodo `connect()` del dispatcher, è possibile registrare qualsiasi callable PHP (o un metodo di classe o una funzione) da chiamare quando si verifica un evento. Il primo argomento di `connect()` è l'identificatore dell'evento, che è una stringa composta da uno spazio nomi e da un nome. Il secondo argomento è un callable PHP.
 
 >**Note**
 >Recuperare il dispatcher degli eventi da un qualsiasi punto dell'applicazione:
@@ -164,7 +164,7 @@ Listato 17-4 - Gestire un evento del tipo "notificare finché"
 
 In pratica, `notifyUntil()` aggiunge funzionalità di ereditarietà multipla, o meglio mixin (l'aggiunta di metodi da parte di classi esterne rispetto a una classe esistente), al PHP. Quindi ora si possono "iniettare" nuovi metodi agli oggetti che non si possono estendere atrtaverso l'ereditarietà. E questo avviene a runtime. Non si è più limitati dalle capacità orientate agli oggetti di PHP quando si utilizza symfony.
 
->**TIP**: Essendo che il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo ad essere registrato, è il primo ad essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi a una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
+>**TIP**: Essendo che il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo a essere registrato, è il primo a essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi a una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
 
 ### Cambiare il valore di ritorno di un metodo
 
@@ -293,14 +293,15 @@ Listato 17-6 - Registrare un ascoltatore nella classe di configurazione  dell'ap
 I plugin (vedere sotto) possono registrare i propri ascoltatori di eventi. Dovrebbero farlo nello script `config/config.php` del plugin, che viene eseguito durante l'inizializzazione dell'applicazione e offre l'accesso al dispatcher di eventi attraverso `$this->dispatcher`.
 
 Factory
----------
+-------
 
-Factory è la definizione di una classe per un determinato compito. Symfony per le sue caratteristiche del core, come la gestione del controllore e della sessione, si basa su factory. Ad esempio, quando il framework deve creare un oggetto per un nuova richiesta, cerca nella definizione della factory il nome della classe da utilizzare a tale scopo. La definizione predefinita della factory per le richieste è `sfWebRequest`, quindi symfony crea un oggetto di questa classe, al fine di gestire le richieste. Il grande vantaggio di utilizzare una definizione della factory è che è molto facile alterare le caratteristiche core del framework: basta cambiare la definizione della factory e symfony userà la classe personalizzata per la richiesta, invece della sua.
+Factory è la definizione di una classe per un determinato compito. Symfony per le sue caratteristiche del core, come la gestione del controllore e della sessione, si basa su factory. Ad esempio, quando il framework deve creare un oggetto per un nuova richiesta, cerca nella definizione del factory il nome della classe da utilizzare a tale scopo. La definizione predefinita del factory per le richieste è `sfWebRequest`, quindi symfony crea un oggetto di questa classe, al fine di gestire le richieste. Il grande vantaggio di utilizzare una definizione del factory è che è molto facile alterare le caratteristiche core del framework: basta cambiare la definizione del factory e symfony userà la classe personalizzata per la richiesta, invece della sua.
 
-Le definizioni delle factory sono memorizzate nel file di configurazione `factories.yml`. Il Listato 17-7 mostra il file con le definizioni predefinite delle factory. Ogni definizione è costituita dal nome di una classe autocaricata e (opzionalmente) da un insieme di parametri. Per esempio, la factory per la memorizzazione delle sessioni (impostata sotto la chiave `storage:`), utilizza un parametro `session_name` per dare un nome al cookie creato sul computer client, che consente le sessioni persistenti.
+Le definizioni dei factory sono memorizzate nel file di configurazione `factories.yml`. Il Listato 17-7 mostra il file con le definizioni predefinite dei factory. Ogni definizione è costituita dal nome di una classe autocaricata e (opzionalmente) da un insieme di parametri. Per esempio, il factory per la memorizzazione delle sessioni (impostata sotto la chiave `storage:`), utilizza un parametro `session_name` per dare un nome al cookie creato sul computer client, che consente le sessioni persistenti.
 
-Listato 17-7 - File predefinito per le factory, in `frontend/config/factories.yml`
+Listato 17-7 - File predefinito per i factory, in `frontend/config/factories.yml`
 
+    [yml]
     -
     prod:
       logger:
@@ -342,9 +343,9 @@ Listato 17-7 - File predefinito per le factory, in `frontend/config/factories.ym
           cache_key_use_vary_headers: true
           cache_key_use_host_name:    true
 
-Il modo migliore per cambiare una factory è quello di creare una nuova classe che eredita dalla factory predefinita e aggiungere nuovi metodi ad essa. Per esempio, la factory della sessione utente è impostata con la classe `myUser` (che si trova in `frontend/lib/`) ed eredita da `sfUser`. Utilizzare lo stesso meccanismo per trarre beneficio dalle factory esistenti. Il Listato 17-8 mostra un esempio di una nuova factory per l'oggetto request.
+Il modo migliore per cambiare un factory è quello di creare una nuova classe che eredita dal factory predefinito e aggiungervi nuovi metodi. Per esempio, il factory della sessione utente è impostato con la classe `myUser` (che si trova in `frontend/lib/`) ed eredita da `sfUser`. Utilizzare lo stesso meccanismo per trarre beneficio dai factory esistenti. Il Listato 17-8 mostra un esempio di un nuovo factory per l'oggetto request.
 
-Listato 17-8 - Sovrascrivere le factory
+Listato 17-8 - Sovrascrivere i factory
 
     [php]
     // Creare un file myRequest.class.php in una cartella con autocaricamento,
@@ -608,7 +609,7 @@ Ci sono alcuni elementi che il task `plugin:install` non può gestire da solo e
   * Configurazione personalizzate dell'applicazione possono essere utilizzate nel codice del plugin (ad esempio, utilizzando `sfConfig::get('app_myplugin_foo')`), ma non si possono mettere i valori predefiniti in un file `app.yml` che si trova nella cartella `config/` del plugin. Per gestire i valori predefiniti, si usa il secondo argomento del metodo `sfConfig::get()`. Le impostazioni possono comunque essere sovrascritte a livello di applicazione (vedere il Listato 17-25 per un esempio).
   * Le regole personalizzate delle rotte devono essere aggiunte manualmente nel file `routing.yml` dell'applicazione.
   * I filtri personalizzati devono essere aggiunti manualmente nel file `filters.yml` dell'applicazione.
-  * Le factory personalizzate devono essere aggiunte manualmente nel file `factories.yml` dell'applicazione.
+  * I factory personalizzati devono essere aggiunti manualmente nel file `factories.yml` dell'applicazione.
 
 In generale, tutta la configurazione che dovrebbe finire in uno dei file di configurazione dell'applicazione deve essere aggiunta manualmente. I plugin con tali impostazioni manuali dovrebbero incorporare un file `README` che descrive i dettagli dell'installazione.
 
@@ -985,7 +986,7 @@ I plugin devono sempre includere un file `LICENSE` che descrive le condizioni di
 Riepilogo
 ---------
 
-Le classi di symfony notificano eventi che danno loro la possibilità di essere modificati a livello di applicazione. Il meccanismo degli eventi permette l'ereditarietà multipla e la sovrascrittura delle classi in fase di runtime, anche se le limitazioni di PHP lo impedirebbero. Quindi le funzionalità di symfony si possono estendere facilmente, anche quando è necessario modificare le classi core: la configurazione delle factory è qui per questo.
+Le classi di symfony notificano eventi che danno loro la possibilità di essere modificati a livello di applicazione. Il meccanismo degli eventi permette l'ereditarietà multipla e la sovrascrittura delle classi in fase di runtime, anche se le limitazioni di PHP lo impedirebbero. Quindi le funzionalità di symfony si possono estendere facilmente, anche quando è necessario modificare le classi core: la configurazione dei factory è qui per questo.
 
 Molte estensioni esistono già, sono pacchettizzate come plugin, per essere installate facilmente, aggiornate e disinstallate tramite la riga di comando di symfony. Creare un plugin è facile come creare un pacchetto PEAR e fornisce riutilizzabilità tra le applicazioni.
 
diff --git a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
index 674a8c5..be9815d 100644
--- a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
+++ b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
@@ -1,16 +1,16 @@
-Appendice A - All'interno dello strato modello (Propel)
-===========================================
+Appendice A - All'interno del livello del modello (Propel)
+==========================================================
 
-Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su uno strato che mappa oggetti e relazioni. Symfony è in bundle con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
+Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su un livello che mappa oggetti e relazioni. Symfony è distrubuito con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
 
 Questo capitolo spiega come creare un modello di dati a oggetti e come accedere ai dati e modificarli con Propel. Viene anche trattata l'integrazione di Propel con symfony.
 
-Perché usare un ORM e uno strato per l'astrazione?
-----------------------------------------
+Perché usare un ORM e un livello per l'astrazione?
+--------------------------------------------------
 
-I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM), ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
+I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM) ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
 
-Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Lo strato ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
+Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
 
 Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo accessor alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
 
@@ -38,11 +38,11 @@ Listato 8-2 - Il metodo accessor maschera la logica dei dati
       return $total;
     }
 
-C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo dello strato di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL.
+C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL.
 
 Il principale vantaggio del livello di astrazione è la portabilità, perché rende possibile il passaggio a un'altra base di dati, anche nel bel mezzo di un progetto. Si supponga di dover scrivere rapidamente un prototipo per un'applicazione, ma il cliente non ha ancora deciso quale sistema di base dati può essere la più adatto alle sue esigenze. Si può cominciare a costruire l'applicazione con SQLite, per esempio e passare a MySQL, PostgreSQL, Oracle quando il cliente ha fatto la scelta. Per fare il cambiamento, basta cambiare una riga in un file di configurazione.
 
-Symfony usa Propel o Doctrine come ORM, e questi usano oggetti PHP per l'astrazione dei dati del database. Queste due componenti di terze parti, entrambi sviluppati dal team di Propel e Doctrine, sono perfettamente integrati in symfony, ed è possibile considerarli come parte del framework. La loro sintassi e le loro convenzioni, descritte in questo capitolo, sono state adattate in modo da differenziarsi il meno possibile da quelle di symfony.
+Symfony usa Propel o Doctrine come ORM, e questi usano oggetti PHP per l'astrazione dei dati del database. Queste due componenti di terze parti, entrambi sviluppati dal team di Propel e Doctrine, sono perfettamente integrati in symfony ed è possibile considerarli come parte del framework. La loro sintassi e le loro convenzioni, descritte in questo capitolo, sono state adattate in modo da differenziarsi il meno possibile da quelle di symfony.
 
 >**NOTE**
 >In un progetto symfony, tutte le applicazioni condividono lo stesso modello. Questo è un punto fondamentale a livello di progetto: raggruppare le applicazioni che si basano su regole di business comuni. Questa è la ragione per cui il modello è indipendente dalle applicazioni e i file del modello sono memorizzati in una cartella `lib/model/` nella radice del progetto.
@@ -99,7 +99,7 @@ Una tabella può avere attributi speciali, incluso `phpName` (il nome della clas
 
 Una tabella contiene colonne. Il valore delle colonne può essere definito in tre differenti modi:
 
-  * Se non definisci nulla (`~` in YAML equivale a `null` in PHP), symfony indovinerà i migliori attributi in base al nome della colonna ed alcune convenzioni che saranno descritte nella sezione "Colonne vuote" più avanti in questo capitolo. Per esempio, la colonna `id` nel Listato 8-3 non ha bisogno di essere definita: Symfony la renderà un intero auto incrementale, chiave primaria della tabella. La colonna `blog_article_id` nella tabella `blog_comment` sarà capita come una chiave esterna verso la tabella `blog_article` (le colonne che terminano con `_id` sono considerate chiave esterne, e la tabella collegata è determinata automaticamente a seconda della prima parte del nome della colonna). Le colonne chiamate `created_at` sono automaticamente impostate al tipo `timestamp`. Per queste colonne, non devi specificare nessun tipo. Questo è il motivo per cui `schema.yml` è così semplice da scrivere.
+  * Se non definisci nulla (`~` in YAML equivale a `null` in PHP), symfony indovinerà i migliori attributi in base al nome della colonna e alcune convenzioni che saranno descritte nella sezione "Colonne vuote" più avanti in questo capitolo. Per esempio, la colonna `id` nel Listato 8-3 non ha bisogno di essere definita: Symfony la renderà un intero auto incrementale, chiave primaria della tabella. La colonna `blog_article_id` nella tabella `blog_comment` sarà capita come una chiave esterna verso la tabella `blog_article` (le colonne che terminano con `_id` sono considerate chiave esterne, e la tabella collegata è determinata automaticamente a seconda della prima parte del nome della colonna). Le colonne chiamate `created_at` sono automaticamente impostate al tipo `timestamp`. Per queste colonne, non devi specificare nessun tipo. Questo è il motivo per cui `schema.yml` è così semplice da scrivere.
 
   * Se definisci soltanto un attributo, questo sarà il tipo della colonna. Symfony conosce i classici tipi: `boolean`, `integer`, `float`, `date`, `varchar(lunghezza)`, `longvarchar` (convertito, per esempio, a `text` in MySQL), e così via. Per stringhe superiori ai 256 caratteri devi usare il valore `longvarchar` che non ha lunghezza (ma non può eccedere 65KB in MySQL).
 
@@ -107,11 +107,11 @@ Una tabella contiene colonne. Il valore delle colonne può essere definito in tr
 
 Le colonne possono avere un attributi `phpName`, che è la versione con prima lettera maiuscola del nome (`Id`, `Title`, `Content`, e così via) e non ha bisogno di essere specificata nella maggior parte dei casi.
 
-Le tabelle possono inoltre contenere esplicite chiavi esterne ed indici, come anche alcune definizioni specifiche per alcuni database. Controlla la sezione `Sintassi estesa dello schema` più avanti in questo capitolo per saperne di più.
+Le tabelle possono inoltre contenere esplicite chiavi esterne e indici, come anche alcune definizioni specifiche per alcuni database. Controlla la sezione `Sintassi estesa dello schema` più avanti in questo capitolo per saperne di più.
 
 Le classi del modello
 -------------
-Lo schema è usato per costruire le classi del modello nello strato ORM. Per risparmiare tempo di esecuzione, queste classi sono generate con un task a riga di comando chiamato `propel:build-model`.
+Lo schema è usato per costruire le classi del modello nel livello ORM. Per risparmiare tempo di esecuzione, queste classi sono generate con un task a riga di comando chiamato `propel:build-model`.
 
     $ php symfony propel:build-model
 
@@ -226,7 +226,7 @@ Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
 
 ### Recuperare i record correlati
 
-La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamente una chiave esterna verso la tabella `blog_article`. Ogni commento è collegato ad un articolo, ed un articolo può avere più commenti. Le classi generate possono contenere cinque metodi che traducono queste relazioni in codice ad oggetti, come segue:
+La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamente una chiave esterna verso la tabella `blog_article`. Ogni commento è collegato ad un articolo e un articolo può avere più commenti. Le classi generate possono contenere cinque metodi che traducono queste relazioni in codice ad oggetti, come segue:
 
   * `$comment->getArticle()`: Per ottenere il relativo oggetto `Article`
   * `$comment->getArticleId()`: Per ottenere l'ID del relativo oggetto `Article`
@@ -234,7 +234,7 @@ La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamen
   * `$comment->setArticleId($id)`: Per impostare il relativo oggetto `Article` tramite il suo ID
   * `$article->getComments()`: Per ottenere un array con i relativi oggetti `Comment`
 
-I metodi `getArticleId()` e `setArticleId()` mostrano che puoi considerare la colonna `blog_article_id` come una colonna normale ed impostare le relazioni a mano, ma non sono molto interessanti. Il beneficio dell'approccio orientato agli oggetti è molto più evidente negli altri tre metodi. Il Listato 8-9 mostra come usare il setter generati.
+I metodi `getArticleId()` e `setArticleId()` mostrano che puoi considerare la colonna `blog_article_id` come una colonna normale e impostare le relazioni a mano, ma non sono molto interessanti. Il beneficio dell'approccio orientato agli oggetti è molto più evidente negli altri tre metodi. Il Listato 8-9 mostra come usare il setter generati.
 
 Listato 8-9 - Le chiavi esterne sono tradotte in speciali setter
 
@@ -270,7 +270,7 @@ Il metodo `getArticle()` ritorna un oggetto di classe `Article`, con i benefici
 La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe `Comment`. Puoi mostrare il primo con `$comments[0]` o iterare sulla collezione con `foreach ($comments as $comment)`.
 
 >**NOTE**
->Oggetti del modello sono definiti con un nome singolare per convenzione, ed ora puoi capire perché. La chiave esterna definita nella tabelle `blog_comment` causa la creazione del metood `getComments()`, chiamato aggiungendo una `s` al nome dell'oggetto `Comment`. Se tu dessi un nome plurale al modello, la generazione porterebbe ad un metodo chiamato `getCommentss()`, che non avrebbe senso.
+>Oggetti del modello sono definiti con un nome singolare per convenzione, e ora si capisce perché. La chiave esterna definita nella tabelle `blog_comment` causa la creazione del metood `getComments()`, chiamato aggiungendo una `s` al nome dell'oggetto `Comment`. Se tu dessi un nome plurale al modello, la generazione porterebbe ad un metodo chiamato `getCommentss()`, che non avrebbe senso.
 
 ### Salvare ed eliminare dati
 
@@ -334,7 +334,7 @@ Listato 8-12 - Recuperare record usando Criteria e `doSelect()`--Criteria vuoto
 >
 >La chiamata a `::doSelect()` è a dir la verità molto più potente di una semplice query SQL. Per prima cosa, il codice SQL generato è ottimizzato per il DBMS scelto. Secondo, su ogni valore passato a `Criteria` viene effettuato l'escape prima di venir intergrato nel codice SQL, che previene rischi di SQL injection. Terzo, questo metodo ritorna un array di oggetti piuttosto che una risorsa PHP. L'ORM crea automaticamente gli oggetti basandosi sulla risorsa ritornata dal database. Questo processo è chiamato idratazione.
 
-Per una selezione più complessa, avrai bisogno degli equivalenti di WHERE, ORDER BY, GROUP BY ed altre istruzioni SQL. L'oggetto `Criteria` ha metodi e parametri per tutte queste condizioni. Per esempio, per ottenere tutti i commenti scritti da Steve, ordinati per data, costruisci un `Criteria` come mostrato nel Listato 8-13.
+Per una selezione più complessa, avrai bisogno degli equivalenti di WHERE, ORDER BY, GROUP BY e altre istruzioni SQL. L'oggetto `Criteria` ha metodi e parametri per tutte queste condizioni. Per esempio, per ottenere tutti i commenti scritti da Steve, ordinati per data, costruisci un `Criteria` come mostrato nel Listato 8-13.
 
 Listato 8-13 - Recuperare record usando Criteria e `doSelect()`--Criteria con condizioni
 
@@ -403,7 +403,7 @@ Listato 8-14 - Un altro esempio di recuperato record con Criteria e `doSelect()`
            AND blog_comment.ARTICLE_ID = blog_article.ID
     ORDER BY blog_comment.CREATED_AT ASC
 
-Come SQL è un linguaggio semplice che consente di gestire interrogazioni molto complesse, l'oggetto Criteria può gestire condizioni con ogni livello di complessità. Ma dato che molti sviluppatori pensano in SQL prima di tradurre una condizione in logica object-oriented, l'oggetto `Criteria` può essere difficile da comprendere all'inizio. Il miglior modo di capirlo è imparare dagli esempi ed applicazioni esistenti. Il sito di symfony, per esempio, è pieno di esempi di utilizzo di `Criteria` che ti aiuteranno in molte situazioni.
+Come SQL è un linguaggio semplice che consente di gestire interrogazioni molto complesse, l'oggetto Criteria può gestire condizioni con ogni livello di complessità. Ma dato che molti sviluppatori pensano in SQL prima di tradurre una condizione in logica object-oriented, l'oggetto `Criteria` può essere difficile da comprendere all'inizio. Il miglior modo di capirlo è imparare dagli esempi e applicazioni esistenti. Il sito di symfony, per esempio, è pieno di esempi di utilizzo di `Criteria` che ti aiuteranno in molte situazioni.
 
 In aggiunta al metodo `doSelect()`, ogni classe peer ha un metodo `doCount()`, che semplicemente ritorna il numero di record che soddisfano i requisiti passati come parametri e ritorna un numero intero. Dato che nessun oggetto viene ritornato, il processo di idratazione non viene eseguito in questo caso, perciò il metodo `doCount()` è più veloce di `doSelect()`.
 

From 6495efe17cfc9fce22a5bddf39028a37825c5a0c Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Tue, 31 Aug 2010 17:17:17 +0200
Subject: [PATCH 05/10] [gentle][it] minor fixes

---
 .../04-The-Basics-of-Page-Creation.markdown   |  4 +-
 .../it/07-Inside-the-View-Layer.markdown      |  6 +--
 ...8-Inside-the-Model-Layer-Doctrine.markdown |  2 +-
 .../it/17-Extending-Symfony.markdown          |  7 ++--
 .../A-Inside-the-Model-Layer-Propel.markdown  | 38 +++++++++----------
 5 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown b/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
index 6f9577d..47a30af 100644
--- a/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
+++ b/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
@@ -49,7 +49,7 @@ Per ogni nuovo modulo, symfony crea una azione `index` predefinita. Questa si co
 L'azione predefinita `index` non verrà usata in questo capitolo, quindi si può rimuovere il metodo `executeIndex()` dal file `actions.class.php` e cancellare il file `indexSuccess.php` dalla cartella `templates/`.
 
 >**NOTE**
->Symfony mette a disposizione altri modi per creare un modulo oltre che da riga di comando. Uno di questi è quello di creare le cartelle e i file manualmente. In molti casi, le azioni e i template di un modulo hanno lo scopo di manipolare i dati di una determinata tabella. Essendo che il codice necessario per creare, recuperare, aggiornare ed eliminare record da una tabella è spesso lo stesso, symfony fornisce un meccanismo per generare tale codice.
+>Symfony mette a disposizione altri modi per creare un modulo oltre che da riga di comando. Uno di questi è quello di creare le cartelle e i file manualmente. In molti casi, le azioni e i template di un modulo hanno lo scopo di manipolare i dati di una determinata tabella. Essendo il codice necessario per creare, recuperare, aggiornare ed eliminare record da una tabella spesso lo stesso, symfony fornisce un meccanismo per generare tale codice.
 
 Figura 4-1 - La pagina index creata in modo predefinito
 
@@ -235,7 +235,7 @@ Listato 4-10 - Molti helper accettano opzioni come parametri
 Ogni volta che si utilizza un helper di symfony che genera un tag HTML, è possibile inserire ulteriori attributi al tag (come l'attributo `class` nell'esempio del Listato 4-10) nelle opzioni. Questi attributi si possono anche scrivere nel modo "sporco e veloce" dell'HTML 4.0 (senza i doppi apici) e symfony li mostrerà con una formattazione XHTML. Questa è un'altra ragione per cui gli helper sono più veloci da scrivere rispetto all'HTML.
 
 >**NOTE**
->Essendo che è necessaria una ulteriore analisi e trasformazione la sintassi con stringa è un po' più lenta della sintassi con gli array.
+>Essendo necessaria una ulteriore analisi e trasformazione, la sintassi con stringa è un po' più lenta della sintassi con gli array.
 
 Come tutti gli helper di symfony, gli helper per i link sono numerosi e hanno molte opzioni. Il Capitolo 9 li descrive in dettaglio.
 
diff --git a/gentle-introduction/it/07-Inside-the-View-Layer.markdown b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
index 225a86e..bbe5549 100644
--- a/gentle-introduction/it/07-Inside-the-View-Layer.markdown
+++ b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
@@ -428,7 +428,7 @@ Listato 7-15 - Inclusione di uno slot `'sidebar'` nel layout
     <?php endif; ?>
     </div>
 
-Ciascun template ha la possibilità di definire i contenuti di uno slot (in realtà anche i partial sono in grado di farlo). Essendo che gli slot sono destinati a contenere codice HTML, symfony offre un modo conveniente per definirli: basta scrivere il codice dello slot tra l'helper `slot()` e `end_slot()`, come mostrato nel Listato 7-16.
+Ciascun template ha la possibilità di definire i contenuti di uno slot (in realtà anche i partial sono in grado di farlo). Essendo gli slot destinati a contenere codice HTML, symfony offre un modo conveniente per definirli: basta scrivere il codice dello slot tra gli helper `slot()` e `end_slot()`, come mostrato nel Listato 7-16.
 
 Listato 7-16 - Sovrascrivere il contenuto dello slot `'sidebar'` in un template
 
@@ -436,13 +436,13 @@ Listato 7-16 - Sovrascrivere il contenuto dello slot `'sidebar'` in un template
     // ...
 
     <?php slot('sidebar') ?>
-      <!-- codice per la barra laterale personalizzata per il template corrente-->
+      <!-- codice per la barra laterale personalizzata per il template corrente -->
       <h1>Dettagli dell'utente</h1>
       <p>nome:  <?php echo $user->getNome() ?></p>
       <p>email: <?php echo $user->getEmail() ?></p>
     <?php end_slot() ?>
 
-Il codice tra gli helper slot è eseguito nel contesto del template, quindi ha accesso a tutte le variabili che sono state definite nell'azione. Symfony metterà automaticamente il risultato dell'esecuzione del codice nell'oggetto response. Non verrà visualizzato nel template, ma reso disponibile per future chiamate `include_slot()` come quella mostrata nel Listato 7-14.
+Il codice tra gli helper slot è eseguito nel contesto del template, quindi ha accesso a tutte le variabili che sono state definite nell'azione. Symfony metterà automaticamente il risultato dell'esecuzione del codice nell'oggetto response. Non verrà visualizzato nel template, ma reso disponibile per future chiamate `include_slot()`, come quella mostrata nel Listato 7-14.
 
 Gli slot sono molto utili per definire zone che devono mostrare dei contenuti contestuali. Possono anche essere usati per aggiungere codice HTML al layout solo per certe azioni. Ad esempio, un template che mostra l'elenco delle ultime news potrebbe volere aggiungere un link a un feed RSS nella zona `<head>` del layout. Questo si può ottenere semplicemente aggiungendo uno slot 'feed'` nel layout e sovrascrivendolo nel template dell'elenco.
 
diff --git a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
index 88af3c8..796c9c5 100644
--- a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
+++ b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
@@ -297,7 +297,7 @@ Se si conosce la chiave primaria di un certo record usare il metodo `find()` del
     [php]
     $articolo = Doctrine_Core::getTable('Articolo')->find(7);
 
-Il file `schema.yml` definisce il campo `id` come chiave primaria della tabella `blog_articolo`, quindi questo comando restituirà l'articolo che ha `id` 7. Essendo che è stata utilizzata la chiave primaria, sappiamo che verrà restituito solo un record; la variabile `$articolo` contiene un oggetto della classe `Articolo`.
+Il file `schema.yml` definisce il campo `id` come chiave primaria della tabella `blog_articolo`, quindi questo comando restituirà l'articolo che ha `id` 7. Essendo stata utilizzata la chiave primaria, sappiamo che verrà restituito solo un record; la variabile `$articolo` contiene un oggetto della classe `Articolo`.
 
 In alcuni casi, una chiave primaria piò essere costituita da più di una colonna. Per gestire questi casi, il metodo `find()` accetta parametri multipli, uno per ciascuna chiave primaria di colonna.
 
diff --git a/gentle-introduction/it/17-Extending-Symfony.markdown b/gentle-introduction/it/17-Extending-Symfony.markdown
index 70affa4..49385c2 100644
--- a/gentle-introduction/it/17-Extending-Symfony.markdown
+++ b/gentle-introduction/it/17-Extending-Symfony.markdown
@@ -164,7 +164,8 @@ Listato 17-4 - Gestire un evento del tipo "notificare finché"
 
 In pratica, `notifyUntil()` aggiunge funzionalità di ereditarietà multipla, o meglio mixin (l'aggiunta di metodi da parte di classi esterne rispetto a una classe esistente), al PHP. Quindi ora si possono "iniettare" nuovi metodi agli oggetti che non si possono estendere atrtaverso l'ereditarietà. E questo avviene a runtime. Non si è più limitati dalle capacità orientate agli oggetti di PHP quando si utilizza symfony.
 
->**TIP**: Essendo che il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo a essere registrato, è il primo a essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi a una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
+>**TIP**
+>Poiché il primo ascoltatore che cattura un evento `notifyUntil()` impedisce ulteriori notifiche, bisogna prestare attenzione all'ordine con cui vengono eseguiti gli ascoltatori. Questo ordine corrisponde all'ordine in cui gli ascoltatori sono stati registrati - il primo a essere registrato, è il primo a essere eseguito. Nella pratica, i casi in cui questo potrebbe essere un problema sono rari. Se ci si rende conto che due ascoltatori sono in conflitto su un particolare evento, forse la classe dovrebbe notificare eventi diversi, per esempio uno all'inizio e uno alla fine dell'esecuzione del metodo. E se si utilizzano gli eventi per aggiungere nuovi metodi a una classe esistente, è meglio dare un nome appropriato a questi metodi, in modo che altre volte in cui si aggiungono metodi non si creino dei conflitti. Prefissare i nomi dei metodi con il nome della classe dell'ascoltatore è una buona pratica.
 
 ### Cambiare il valore di ritorno di un metodo
 
@@ -727,11 +728,11 @@ Listato 17-21 - Personalizzare l'azione di un plugin
 >         created_at:
 >         stripped_title: varchar(50)
 >
->Essendo che il processo di fusione usa la tabella `phpName` come chiave, si può anche cambiare il nome della tabella di un plugin nel database, a condizione che si mantiene lo stesso `phpName` nello schema.
+>Poiché il processo di fusione usa la tabella `phpName` come chiave, si può anche cambiare il nome della tabella di un plugin nel database, a condizione che si mantenga lo stesso `phpName` nello schema.
 
 ### Come scrivere un plugin
 
-Solo i plugin pacchettizzati con PEAR possono essere installati con il task `plugin:install`. È bene ricordare che tali plugin possono essere distribuiti attraverso la sezione plugin di symfony, un canale PEAR, o un semplice file per il download. Quindi se si vuole scrivere un plugin, è meglio pubblicarlo come pacchetto PEAR che come semplice file di archivio. Inoltre, i plugin che utilizzano PEAR sono più facili da aggiornare, possono dichiarare dipendenze e fare il deploy in automatico delle risorse nella cartella `web/`.
+Solo i plugin pacchettizzati con PEAR possono essere installati con il task `plugin:install`. È bene ricordare che tali plugin possono essere distribuiti attraverso la sezione plugin di symfony, un canale PEAR o un semplice file da scaricare. Quindi, se si vuole scrivere un plugin, è meglio pubblicarlo come pacchetto PEAR che come semplice file archivio. Inoltre, i plugin che utilizzano PEAR sono più facili da aggiornare, possono dichiarare dipendenze e fare il deploy in automatico delle risorse nella cartella `web/`.
 
 #### Organizzazione dei file
 
diff --git a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
index be9815d..dab8be4 100644
--- a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
+++ b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
@@ -1,7 +1,7 @@
 Appendice A - All'interno del livello del modello (Propel)
 ==========================================================
 
-Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su un livello che mappa oggetti e relazioni. Symfony è distrubuito con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
+Gran parte della trattazione finora è stata dedicata alla costruzione di pagine e all'elaborazione delle richieste e delle risposte. Ma la business logic di una applicazione web si basa principalmente sul suo modello di dati. Il componente predefinito di symfony per il modello, è basato su un livello che mappa oggetti e relazioni. Symfony è distribuito con i due più popolari ORM per PHP: [Propel](http://www.propelorm.org/) e [Doctrine](http://www.doctrine-project.org/). In un'applicazione symfony, si accede ai dati memorizzati in un database e li si modifica, attraverso gli oggetti; non è necessario riferirsi direttamente al database. Quest'ultimo mantiene un elevato livello di astrazione e portabilità.
 
 Questo capitolo spiega come creare un modello di dati a oggetti e come accedere ai dati e modificarli con Propel. Viene anche trattata l'integrazione di Propel con symfony.
 
@@ -10,11 +10,11 @@ Perché usare un ORM e un livello per l'astrazione?
 
 I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM) ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
 
-Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
+Il vantaggio principale di un ORM è la riusabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
 
-Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo accessor alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
+Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo di accesso alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
 
-Listato 8-1 - Il metodo accessor maschera la struttura della tabella in una classe del modello
+Listato 8-1 - Il metodo di accesso maschera la struttura della tabella in una classe del modello
 
     [php]
     public function getName()
@@ -38,7 +38,7 @@ Listato 8-2 - Il metodo accessor maschera la logica dei dati
       return $total;
     }
 
-C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL.
+C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro database costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale del codice SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del database e di ottimizzare il codice SQL.
 
 Il principale vantaggio del livello di astrazione è la portabilità, perché rende possibile il passaggio a un'altra base di dati, anche nel bel mezzo di un progetto. Si supponga di dover scrivere rapidamente un prototipo per un'applicazione, ma il cliente non ha ancora deciso quale sistema di base dati può essere la più adatto alle sue esigenze. Si può cominciare a costruire l'applicazione con SQLite, per esempio e passare a MySQL, PostgreSQL, Oracle quando il cliente ha fatto la scelta. Per fare il cambiamento, basta cambiare una riga in un file di configurazione.
 
@@ -91,10 +91,10 @@ Notare che il nome del database (`blog`) non compare nel file `schema.yml`. Il d
 
 In un file `schema.yml`, la prima chiave rappresenta un nome della connessione. Può contenere diverse tabelle, ognuna con un set di colonne. In base alla sintassi YAML, le chiavi terminano con un simbolo di due punti, e la struttura è mostrata tramite indentazione (uno o più spazi, non tabulazioni).
 
-Una tabella può avere attributi speciali, incluso `phpName` (il nome della classe che verrà generata). Se non vuoi usare un `phpName` per una tabella, symfony lo creerà in base alla versione camelCase del nome della tabella stessa.
+Una tabella può avere attributi speciali, incluso `phpName` (il nome della classe che verrà generata). Se non si vuole usare un `phpName` per una tabella, symfony lo creerà in base alla versione camelCase del nome della tabella stessa.
 
 >**TIP**
->La convezione camelCase rimuove i trattini bassi dalle parole, e rende maiuscole le prime lettere delle parole interne. La versione camelCase di default di `blog_articolo` e `blog_commento` sono `BlogArticolo` e `BlogCommento`. Il nome di questa convenzione viene dall'aspetto delle lettere maiuscole all'interno di una lunga parola, come le gobbe di un cammello.
+>La convezione camelCase rimuove i trattini bassi dalle parole, e rende maiuscole le prime lettere delle parole interne. Le versioni camelCase predefinite di `blog_articolo` e `blog_commento` sono `BlogArticolo` e `BlogCommento`. Il nome di questa convenzione viene dall'aspetto delle lettere maiuscole all'interno di una lunga parola, come le gobbe di un cammello.
 
 
 Una tabella contiene colonne. Il valore delle colonne può essere definito in tre differenti modi:
@@ -138,7 +138,7 @@ Sono stati definiti solo due modelli e ci si ritrova con otto file. Non c'è nul
 
 Perché tenere due versioni dello stesso modello a oggetti dei dati, in due diverse cartelle?
 
-Probabilmente si avrà bisogno di aggiungere metodi e proprietà agli oggetti del modello (pensiamo al metodo `getNome()` nel Listato 8-1). Mano a mano che il progetto si evolve, si vorranno aggiungere tabelle o colonne. Ogni volta che si cambia il file `schema.yml`, bisogna rigenerare le classi del modello a oggetti facendo una nuova chiamata di doctrine:build-model. Se i metodi personalizzati venissero scritti nelle classi generate, sarebbero cancellati dopo ogni rigenerazione.
+Probabilmente si avrà bisogno di aggiungere metodi e proprietà agli oggetti del modello (pensiamo al metodo `getNome()` nel Listato 8-1). Mano a mano che il progetto si evolve, si vorranno aggiungere tabelle o colonne. Ogni volta che si cambia il file `schema.yml`, bisogna rigenerare le classi del modello a oggetti facendo una nuova chiamata di propel:build-model. Se i metodi personalizzati venissero scritti nelle classi generate, sarebbero cancellati dopo ogni rigenerazione.
 
 Le classi `Base` presenti nella cartella `lib/model/om/` sono le uniche effettivamente generate dallo schema. Non bisogna mai modificarle, dal momento che nuove ricostruzioni del modello cancelleranno completamente questi file.
 
@@ -179,7 +179,7 @@ Listato 8-6 - Metodi statici per recuperare record sono disponibili nelle classi
 >**NOTE**
 >Da un punto di vista di modello di dati, non potrebbe esserci un oggetto peer. Per questo che i metodi delle classi peer sono chiamati con `::` (operatore per metodi statici), al posto del solito `->` (per le chiamate a metodi d'istanza).
 
-Per questo combinare classi oggetto e peer, base e personalizzate risulta in quattro classi generate per ogni tabella descritta nello schema. A dir la verità, c'è una quinta classe creata nella directory `lib/model/map/`, che contiene metadati riguardo le tabelle ed è necessaria per l'ambiente di esecuzione. Ma dato che probabilmente non avrai mai a che fare con questa classe, te ne puoi tranquillamente dimenticare.
+Per questo combinare classi oggetto e peer, base e personalizzate risulta in quattro classi generate per ogni tabella descritta nello schema. A dir la verità, c'è una quinta classe creata nella directory `lib/model/map/`, che contiene metadati riguardo le tabelle ed è necessaria per l'ambiente di esecuzione. Ma dato che probabilmente non si avrà mai a che fare con questa classe, ce ne si può tranquillamente dimenticare.
 
 Accesso ai dati
 ---------------
@@ -211,7 +211,7 @@ Listato 8-7 - Metodi generati nella classe dell'oggetto
 >**NOTE**
 >La classe oggetto generata si chiama `Article`, che è il `phpName` dato alla tabella `blog_article`. Se `phpName` non è stato definito nello schema, la classe sarebbe stata chiamata `BlogArticle`. Gli accessori e modificatori usano una variante camelCase del nome delle colonne, quindi il metodo `getTitle()` resituirà il valore della colonna `title`.
 
-Impostare diversi valori in un unica volta, puoi usare il metodo `fromArray()`, generato per ogni classe oggetto, come mostrato nel Listato 8-8.
+Impostare diversi valori in un unica volta, si può usare il metodo `fromArray()`, generato per ogni classe oggetto, come mostrato nel Listato 8-8.
 
 Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
 
@@ -222,7 +222,7 @@ Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
     ));
 
 >**NOTE**
->Il metodo `fromArray()` ha un secondo argomento, `keyType`. Puoi specificare il tipo di chiave dell'array passando uno tra `BasePeer::TYPE_PHPNAME`, `BasePeer::TYPE_STUDLYPHPNAME`, `BasePeer::TYPE_COLNAME`, `BasePeer::TYPE_FIELDNAME` e `BasePeer::TYPE_NUM`. Il valore di default è PhpName (i.e. `AuthorId`).
+>Il metodo `fromArray()` ha un secondo parametro, `keyType`. Si può specificare il tipo di chiave dell'array passando uno tra `BasePeer::TYPE_PHPNAME`, `BasePeer::TYPE_STUDLYPHPNAME`, `BasePeer::TYPE_COLNAME`, `BasePeer::TYPE_FIELDNAME` e `BasePeer::TYPE_NUM`. Il valore predefinito è PhpName (i.e. `AuthorId`).
 
 ### Recuperare i record correlati
 
@@ -234,7 +234,7 @@ La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamen
   * `$comment->setArticleId($id)`: Per impostare il relativo oggetto `Article` tramite il suo ID
   * `$article->getComments()`: Per ottenere un array con i relativi oggetti `Comment`
 
-I metodi `getArticleId()` e `setArticleId()` mostrano che puoi considerare la colonna `blog_article_id` come una colonna normale e impostare le relazioni a mano, ma non sono molto interessanti. Il beneficio dell'approccio orientato agli oggetti è molto più evidente negli altri tre metodi. Il Listato 8-9 mostra come usare il setter generati.
+I metodi `getArticleId()` e `setArticleId()` mostrano che si può considerare la colonna `blog_article_id` come una colonna normale e impostare le relazioni a mano, ma non sono molto interessanti. Il beneficio dell'approccio orientato agli oggetti è molto più evidente negli altri tre metodi. Il Listato 8-9 mostra come usare il setter generati.
 
 Listato 8-9 - Le chiavi esterne sono tradotte in speciali setter
 
@@ -267,7 +267,7 @@ Listato 8-10 - Chiavi esterne sono trasformate in speciali getter
 
 Il metodo `getArticle()` ritorna un oggetto di classe `Article`, con i benefici del metodo accessore `getTitle()`. Questo è molto migliore di dover eseguire la join tu stesso, che potrebbe richiedere alcune linee di codice (a partire dalla riga `$comment->getArticleId()`).
 
-La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe `Comment`. Puoi mostrare il primo con `$comments[0]` o iterare sulla collezione con `foreach ($comments as $comment)`.
+La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe `Comment`. Si può mostrare il primo con `$comments[0]` o iterare sulla collezione con `foreach ($comments as $comment)`.
 
 >**NOTE**
 >Oggetti del modello sono definiti con un nome singolare per convenzione, e ora si capisce perché. La chiave esterna definita nella tabelle `blog_comment` causa la creazione del metood `getComments()`, chiamato aggiungendo una `s` al nome dell'oggetto `Comment`. Se tu dessi un nome plurale al modello, la generazione porterebbe ad un metodo chiamato `getCommentss()`, che non avrebbe senso.
@@ -279,12 +279,12 @@ Chiamando il costruttore con `new`, hai creato un nuovo oggetto, ma non un recor
     [php]
     $article->save();
 
-L'ORM è intelligente abbastanza da capire le relazioni tra gli oggetti, quindi salvare l'oggetto `$article` salverà anche il relativo oggetto `$comment`. Conosce inoltre se l'oggetto salvato è già presente nel database, quindi una chiamata a `save()` sarà tradotta in una istruzione `INSERT` oppure `UPDATE` in SQL. La chiave primaria è impostata automaticamente dal metodo `save()`, quindi dopo il salvataggio, puoi recuperare la nuova chiave primaria con `$article->getId()`.
+L'ORM è intelligente abbastanza da capire le relazioni tra gli oggetti, quindi salvare l'oggetto `$article` salverà anche il relativo oggetto `$comment`. Conosce inoltre se l'oggetto salvato è già presente nel database, quindi una chiamata a `save()` sarà tradotta in una istruzione `INSERT` oppure `UPDATE` in SQL. La chiave primaria è impostata automaticamente dal metodo `save()`, quindi dopo il salvataggio, si può recuperare la nuova chiave primaria con `$article->getId()`.
 
 >**TIP**
->Puoi controllare se un oggetto è nuovo chiamando `isNew()`. E se ti domandi se un oggetto è stato modificato e necessita del salvataggio, puoi usare il metodo `isModified()`.
+>Si può controllare se un oggetto è nuovo chiamando `isNew()`. E se ti domandi se un oggetto è stato modificato e necessita del salvataggio, si può usare il metodo `isModified()`.
 
-Se leggi i commenti ai tuoi articoli, potresti cambiare idea riguardo il pubblicare contenuti su internet. E se non apprezzi l'ironia dei lettori, puoi cancellare semplicemente i commenti con il metodo `delete()`, come mostrato nel Listato 8-11.
+Leggendo i commenti agli articoli, si potrebbe cambiare idea riguardo il pubblicare contenuti su Internet. E se non si apprezza l'ironia dei lettori, si possono cancellare semplicemente i commenti con il metodo `delete()`, come mostrato nel Listato 8-11.
 
 Listato 8-11 - Cancellare righe dal database con il metodo `delete()` dell'oggetto
 
@@ -308,11 +308,11 @@ Il file `schema.yml` definisce il campo `id` come la chiave primaria della tabel
 
 In alcuni casi, una chiave primaria può consistere in più di una colonna. In questi casi, il metodo `retrieveByPk()` accetta parametri multipli, uno per ogni colonna della chiave primaria.
 
-Puoi inoltre selezionare multipli oggetti basandoti sulla loro chiave primaria, chiamato in metodo generato `retrieveByPks()`, che ha come parametri un array di chiavi primarie.
+Si possono inoltre selezionare multipli oggetti basandoti sulla loro chiave primaria, chiamato in metodo generato `retrieveByPks()`, che ha come parametri un array di chiavi primarie.
 
 ### Recuperare record con Criteria
 
-Quando vuoi recuperare più di un record, dovrai utilizzare il metodo `doSelect()` della classe peer corrispondente agli oggetti che vuoi ottenere. Per esempio, per recuperare oggetti della classe `Article`, chiama `ArticlePeer::doSelect()`.
+Quando si vuole recuperare più di un record, occorre utilizzare il metodo `doSelect()` della classe peer corrispondente agli oggetti che si vogliono ottenere. Per esempio, per recuperare oggetti della classe `Article`, chiamare `ArticlePeer::doSelect()`.
 
 Il primo parametro del metodo `doSelect()` è un oggetto della classe `Criteria`, che è una semplice classe per la costruzione delle query, senza l'utilizzo di SQL per mantenere l'astrazione dal database.
 
@@ -409,7 +409,7 @@ In aggiunta al metodo `doSelect()`, ogni classe peer ha un metodo `doCount()`, c
 
 La classi peer forniscono inoltre i metodi `doDelete()`, `doInsert()` e `doUpdate()`, che ricevono un oggetto `Criteria` come parametro. Questi metodi consentono di eseguire interrogazioni di tipo `DELETE`, `INSERT` e `UPDATE` sul database. Dai un'occhiata alle classi peer generate nel tuo modello per ulteriori dettagli su questi metodi di Propel.
 
-Infine, se vuoi soltanto il primo oggetto, sostituisci `doSelect()` con `doSelectOne()`. Questo potrebbe essere il caso in cui sai che `Criteria` produrrà un risultato soltanto, con il vantaggio che il metodo ritornerà direttamente un oggetto piuttosto di un array.
+Infine, se si vuole soltanto il primo oggetto, sostituire `doSelect()` con `doSelectOne()`. Questo potrebbe essere il caso in cui si sa che `Criteria` produrrà un risultato soltanto, con il vantaggio che il metodo ritornerà direttamente un oggetto piuttosto di un array.
 
 >**TIP**
 >Quando una query ritorna un gran numero di risultati, potresti volerne mostrare soltanto un sottoinsieme. Symfony fornisce una classe per la suddivisione in pagine chiamata `sfPropelPager`, che automatizza la paginazione dei risultati.

From 176831a932a08a5cdd13b06888526ddfefb95c56 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Wed, 1 Sep 2010 10:39:32 +0200
Subject: [PATCH 06/10] [gentle] fixed customized schema name

---
 gentle-introduction/en/17-Extending-Symfony.markdown |  4 ++--
 gentle-introduction/it/17-Extending-Symfony.markdown | 12 ++++++------
 gentle-introduction/ja/17-Extending-Symfony.markdown |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/gentle-introduction/en/17-Extending-Symfony.markdown b/gentle-introduction/en/17-Extending-Symfony.markdown
index bebff78..0eb082f 100644
--- a/gentle-introduction/en/17-Extending-Symfony.markdown
+++ b/gentle-introduction/en/17-Extending-Symfony.markdown
@@ -693,8 +693,8 @@ Listing 17-21 - Customizing a Plug-In Action
 >-------------------------------------- | ------------------------------
 >config/schema.yml                      | schema.custom.yml
 >config/foobar_schema.yml               | foobar_schema.custom.yml
->plugins/myPlugin/config/schema.yml     | myPlugin_schema.custom.yml
->plugins/myPlugin/config/foo_schema.yml | myPlugin_foo_schema.custom.yml
+>plugins/myPlugin/config/schema.yml     | myPlugin-schema.custom.yml
+>plugins/myPlugin/config/foo_schema.yml | myPlugin_foo-schema.custom.yml
 >
 >Custom schemas will be looked for in the application's and plugins' `config/` directories, so a plugin can override another plugin's schema, and there can be more than one customization per schema.
 >
diff --git a/gentle-introduction/it/17-Extending-Symfony.markdown b/gentle-introduction/it/17-Extending-Symfony.markdown
index 49385c2..acad501 100644
--- a/gentle-introduction/it/17-Extending-Symfony.markdown
+++ b/gentle-introduction/it/17-Extending-Symfony.markdown
@@ -694,12 +694,12 @@ Listato 17-21 - Personalizzare l'azione di un plugin
 >###Propel
 >Quando si costruisce il modello, symfony cercherà i file personalizzati YAML per ogni schema esistente, compresi i plugin, seguendo questa regola:
 >
->Nome originale dello schema            | Nome dello schema personalizzato
->-------------------------------------- | --------------------------------
->config/schema.yml                      | schema.custom.yml
->config/foobar_schema.yml               | foobar_schema.custom.yml
->plugins/mioPlugin/config/schema.yml     | mioPlugin_schema.custom.yml
->plugins/mioPlugin/config/foo_schema.yml | mioPlugin_foo_schema.custom.yml
+>Nome originale dello schema             | Nome dello schema personalizzato
+>--------------------------------------- | --------------------------------
+>config/schema.yml                       | schema.custom.yml
+>config/foobar_schema.yml                | foobar_schema.custom.yml
+>plugins/mioPlugin/config/schema.yml     | mioPlugin-schema.custom.yml
+>plugins/mioPlugin/config/foo_schema.yml | mioPlugin_foo-schema.custom.yml
 >
 >Gli schemi personalizzati saranno cercati nelle cartelle `config/` dell'applicazione e del plugin , quindi un plugin può sovrascrivere lo schema di un'altro plugin e ci può essere più di una personalizzazione per ciascuno schema.
 >
diff --git a/gentle-introduction/ja/17-Extending-Symfony.markdown b/gentle-introduction/ja/17-Extending-Symfony.markdown
index 89bd27d..96c706a 100644
--- a/gentle-introduction/ja/17-Extending-Symfony.markdown
+++ b/gentle-introduction/ja/17-Extending-Symfony.markdown
@@ -723,8 +723,8 @@ PEAR プラグインをアンインストールするには、リスト17-17で
 >-------------------------------------- | ------------------------------
 >config/schema.yml                      | schema.custom.yml
 >config/foobar_schema.yml               | foobar_schema.custom.yml
->plugins/myPlugin/config/schema.yml     | myPlugin_schema.custom.yml
->plugins/myPlugin/config/foo_schema.yml | myPlugin_foo_schema.custom.yml
+>plugins/myPlugin/config/schema.yml     | myPlugin-schema.custom.yml
+>plugins/myPlugin/config/foo_schema.yml | myPlugin_foo-schema.custom.yml
 >
 >カスタムスキーマはアプリケーションとプラグインの `config/` ディレクトリを探すので、プラグインは別のプラグインのスキーマを上書きをして、スキーマ単位で複数のカスタマイズが可能です。
 >

From e07b06a763cf9ed6a0dd1d394a2c503184548ec7 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Wed, 1 Sep 2010 15:49:36 +0200
Subject: [PATCH 07/10] [forms][reference][it] minor fixes

---
 forms/it/01-Form-Creation.txt                 | 10 ++++-----
 forms/it/02-Form-Validation.txt               | 20 ++++++++---------
 forms/it/03-Forms-for-web-Designers.txt       | 12 +++++-----
 forms/it/04-Propel-Integration.txt            | 22 +++++++++----------
 ...-Internationalisation-and-Localisation.txt |  4 ++--
 forms/it/11-Doctrine-Integration.txt          | 20 ++++++++---------
 forms/it/A-Widgets.txt                        |  2 +-
 forms/it/B-Validators.txt                     | 12 +++++-----
 reference/it/01-Introduction.markdown         |  4 ++--
 reference/it/02-YAML.markdown                 |  2 +-
 reference/it/04-Settings.markdown             | 10 ++++-----
 reference/it/05-Factories.markdown            |  6 ++---
 reference/it/06-Admin-Generator.markdown      |  2 +-
 reference/it/08-Security.markdown             |  4 ++--
 reference/it/11-App.markdown                  |  6 ++---
 .../it/14-Other-Configuration-Files.markdown  |  2 +-
 reference/it/15-Events.markdown               |  4 ++--
 reference/it/16-Tasks.markdown                |  2 +-
 18 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/forms/it/01-Form-Creation.txt b/forms/it/01-Form-Creation.txt
index dca0676..fba196b 100644
--- a/forms/it/01-Form-Creation.txt
+++ b/forms/it/01-Form-Creation.txt
@@ -13,7 +13,7 @@ creazione di un progetto symfony.
 Prima di iniziare
 -----------------
 
-Inizieremo aggiungendo un form di contatto ad un'applicazione symfony.
+Inizieremo aggiungendo un form di contatto a un'applicazione symfony.
 
 La Figura 1-1 mostra il form di contatto come viene visto dagli utenti
 che vogliono inviare un messaggio.
@@ -266,7 +266,7 @@ template per personalizzare ulteriormente il form.
 >       'message' => new sfWidgetFormTextarea(),
 >     ));
 >
->Il metodo `setLabels()` è applicato ad un insieme di widget
+>Il metodo `setLabels()` è applicato a un insieme di widget
 >inclusi nell'oggetto `widgetSchema`.
 >
 >Vedremo nel Capitolo 5 che la nozione di "schema widget" rende
@@ -344,7 +344,7 @@ Il metodo `executeSubmit()` esegue tre azioni:
 
   * Per ragioni di sicurezza, verifichiamo che la pagina sia stata
     inviata usando il metodo HTTP `POST`. Se non è stata inviata col
-    metodo `POST`, l'utente è rediretto ad una pagina 404. Nel template
+    metodo `POST`, l'utente è rediretto a una pagina 404. Nel template
     `indexSuccess`, dichiariamo il metodo di invio come `POST`
     (`<form ... method="post">`):
 
@@ -359,13 +359,13 @@ Il metodo `executeSubmit()` esegue tre azioni:
         'email'   => $request->getParameter('email'),
         'message' => $request->getParameter('message'),
       );
-  * Infine, redirigiamo l'utente ad una pagina di ringraziamenti
+  * Infine, redirigiamo l'utente a una pagina di ringraziamenti
     (`contact/thankyou`) per mostrare le sue informazioni:
 
       [php]
       $this->redirect('contact/thankyou?'.http_build_query($params));
 
-Invece di redirigere l'utente ad un'altra pagina, potremmo creare un
+Invece di redirigere l'utente a un'altra pagina, potremmo creare un
 template `submitSuccess.php`. Sebbene sia possibile, è una pratica
 migliore redirigere sempre l'utente dopo una richiesta con metodo `POST`:
 
diff --git a/forms/it/02-Form-Validation.txt b/forms/it/02-Form-Validation.txt
index b774d32..ce25d0e 100644
--- a/forms/it/02-Form-Validation.txt
+++ b/forms/it/02-Form-Validation.txt
@@ -30,7 +30,7 @@ Ecco le regole di validazione da implementare per il form di contatto:
 
 >**NOTE**
 >Perché abbiamo bisogno di validare il campo `subject`? Il tag
->`<select>` costringe già l'utente ad un elenco di valori
+>`<select>` costringe già l'utente a un elenco di valori
 >predefiniti. Un utente medio può solo scegliere una delle opzioni
 >mostrate, ma altri valori possono essere inviati usando degli
 >strumenti come l'estensione Web Developer di Firefox, oppure
@@ -68,7 +68,7 @@ Validatori
 
 Un form in symfony è fatto di campi. Ciascun campo può essere
 identificato da un nome univoco, come osservato nel Capitolo 1.
-Abbiamo connesso un widget ad ogni campo per poterlo mostrare
+Abbiamo connesso un widget a ogni campo per poterlo mostrare
 all'utente, ora vediamo come possiamo applicare le regole di
 validazione a ciascun campo.
 
@@ -136,7 +136,7 @@ Vediamo le opzioni disponibili per i validatori che abbiamo appena usato:
   | sfValidatorChoice | `choices`                |                              |
 
 
-Se si prova ad inviare il form con valori non validi, non si vedrà
+Se si prova a inviare il form con valori non validi, non si vedrà
 alcun cambiamento nel comportamento. Dobbiamo aggiornare il modulo
 `contact` per validare i valori inviati, come mostrato nel Listato 2-3.
 
@@ -175,7 +175,7 @@ Il Listato 2-3 introduce molti nuovi concetti:
 
   * Quando l'utente invia il form con una richiesta `POST`,
     il metodo `bind()` lega il form ai dati utente e attiva
-    il meccanismo di validazione. il form quindi passa ad uno
+    il meccanismo di validazione. il form quindi passa a uno
     **stato vincolato**.
 
         [php]
@@ -343,7 +343,7 @@ Figura 2-5 - Messaggi di errore personalizzati
 ![Messaggi di errore personalizzati](http://www.symfony-project.org/images/forms_book/en/02_05.png "Messaggi di errore personalizzati")
 
 La Figura 2-6 mostra il messaggio di errore ottenuto se si prova
-ad inviare un messaggio troppo corto (abbiamo impostato la
+a inviare un messaggio troppo corto (abbiamo impostato la
 lunghezza minima a 4 caratteri).
 
 Figura 2-6 - Messaggio di errore per stringa troppo corta
@@ -388,8 +388,8 @@ valori disponibili sono solitamente i dati inseriti dall'utente
 (`value`) e i valori delle opzioni del validatore relativo all'errore.
 
 >**TIP**
->Se si vogliono conoscere tutti i codici di errore, le opzioni,
->ed i messaggi predefiniti di un validatore, fare riferimento
+>Se si vogliono conoscere tutti i codici di errore, le opzioni
+>e i messaggi predefiniti di un validatore, fare riferimento
 >alla documentazione online delle API (http://www.symfony-project.org/api/1_2/).
 >Ogni codice, opzione e messaggio di errore è descritto in dettaglio,
 >insieme con i valori predefiniti (per esempio, l'API del
@@ -683,7 +683,7 @@ default, si comportano ignorando ogni altro dato inviato dall'utente,
 ma talvolta la validazione di un campo dipende dal contesto o
 dipende da molti altri campi. Per esempio, serve un validatore
 globale quando due password devono coincidere, oppure quando
-una data d'inizio deve essere antecedente ad una data di fine.
+una data d'inizio deve essere antecedente a una data di fine.
 
 In entrambi questi casi, dobbiamo usare un validatore globale
 per validare i dati inviati dall'utente nel loro contesto.
@@ -715,7 +715,7 @@ L'esempio precedente è equivalente a:
 >di ogni campo.
 
 Il Listato 2-14 mostra come usare un singolo validatore per
-validare una data di inizio che debba essere antecedente ad
+validare una data di inizio che debba essere antecedente a
 una data di fine, personalizzando il messaggio di errore.
 
 Listato 2-14 - Usare il validatore `sfValidatorSchemaCompare`
@@ -736,7 +736,7 @@ sarà sempre convertito in un formato comparabile (di default
 
 Per default, i pre-validatori e i post-validatori restituiscono
 errori globali al form. Tuttavia, alcuni di essi possono associare
-un errore ad un campo specifico. Per esempio, l'opzione
+un errore a un campo specifico. Per esempio, l'opzione
 `throw_global_error` del validatore `sfValidatorSchemaCompare` può
 scegliere tra un errore globale (Figura 2-10) o un errore associato
 al primo campo (Figura 2-11). Il Listato 2-15 mostra come usare
diff --git a/forms/it/03-Forms-for-web-Designers.txt b/forms/it/03-Forms-for-web-Designers.txt
index 9ad02bc..4e381b1 100644
--- a/forms/it/03-Forms-for-web-Designers.txt
+++ b/forms/it/03-Forms-for-web-Designers.txt
@@ -147,7 +147,7 @@ Listato 3-2 - Template generato in caso di invio non valido
 >anche di passare un numero arbitrario di attributi addizionali al tag
 >form in modo più semplice, usando un array. Lo svantaggio di usare questa
 >scorciatoia sta nel fatto che gli strumenti di design avranno più
->difficoltà ad individuare correttamente il form.
+>difficoltà a individuare correttamente il form.
 
 Analizziamo questo codice. La Figura 3-2 evidenzia le righe
 `<tr>` prodotte per ogni campo.
@@ -241,7 +241,7 @@ Listato 3-4 - Uso di `renderRow()`
       </table>
     </form>
 
-Possiamo accedere ad ogni campo usando l'oggetto `form` come un
+Possiamo accedere a ogni campo usando l'oggetto `form` come un
 array PHP. Si può accedere al campo `email` tramite
 `$form['email']`. Il metodo `renderRow()` visualizza il campo
 come una riga di una tabella HTML. L'espressione
@@ -255,7 +255,7 @@ visualizzazione del form.
 >
 >Dalla versione 5 di PHP, agli oggetti possono essere dati gli
 >stessi comportamenti di un array. La classe `sfForm` implementa
->l'interfaccia `ArrayAccess` per consentire l'accesso ad ogni
+>l'interfaccia `ArrayAccess` per consentire l'accesso a ogni
 >campo usando una sintassi breve e semplice. La chiave
 >dell'array è il nome del campo e il valore restituito è
 >associato con l'oggetto `widget`:
@@ -553,7 +553,7 @@ Listato 3-11 - Mostrare i messaggi di errore usando il metodo `renderError()`
 ### Personalizzazione avanzata dei messaggi di errore
 
 Il metodo `renderError()` genera la lista degli errori
-associati ad un campo. Genera codice HTML solo se il campo
+associati a un campo. Genera codice HTML solo se il campo
 ha degli errori. Per default, la list è generata come una
 lista HTML non ordinata (`<ul>`).
 
@@ -633,13 +633,13 @@ Listato 3-14 - Generazione dei messaggi di errore globali
 
 Ci sono tre tipi di errore in un form:
 
-  * Errori associati ad un campo specifico
+  * Errori associati a un campo specifico
   * Errori globali
   * Errori su campi nascosti o su campi che non sono visualizzati
     nel form. Questi sono aggiunti agli errori globali.
 
 Abbiamo già visto l'implementazione dei messaggi di errore associati
-ad un campo e il Listato 3-15 mostra l'implementazione dei
+a un campo e il Listato 3-15 mostra l'implementazione dei
 messaggi di errore globali.
 
 Listato 3-15 - Implementazione dei messaggi di errore globali
diff --git a/forms/it/04-Propel-Integration.txt b/forms/it/04-Propel-Integration.txt
index b3e666d..143d000 100644
--- a/forms/it/04-Propel-Integration.txt
+++ b/forms/it/04-Propel-Integration.txt
@@ -3,7 +3,7 @@ Capitolo 4 - Integrazione con Propel
 
 In un progetto web, la maggior parte dei form è usata per creare o
 modificare oggetti del modello. Questi oggetti sono solitamente
-serializzati in un database grazie ad un ORM. Il sistema di form
+serializzati in un database grazie a un ORM. Il sistema di form
 di symfony offre un livello addizionale per interfacciarsi con
 Propel, l'ORM predefinito in symfony, rendendo l'implementazione
 dei form basati su questi oggetti più facile.
@@ -66,7 +66,7 @@ Ecco le relazioni tra le tabelle:
   * Relazione 1-n tra la tabella `article` e la tabella `author`:
     un articolo è scritto da uno e un solo autore
   * Relazione 1-n tra la tabella `article` e la tabella `category`:
-    un articolo appartiene ad una o nessuna categoria
+    un articolo appartiene a una o nessuna categoria
   * Relazione n-n tra le tabelle `article` e `tag`
 
 Generazione delle classi dei form
@@ -153,7 +153,7 @@ coinvolte nella definizione del form `AuthorForm`.
   | **Classe**      | **Package**   | **Per**       | **Descrizione**
   | --------------- | ------------- | ------------- | ---------------
   | AuthorForm      | project       | sviluppatore  | Sovrascrive il form generato
-  | BaseAuthorForm  | project       | symfony       | Basato sullo schema e sovrascritto ad ogni esecuzione di `propel:build-forms`
+  | BaseAuthorForm  | project       | symfony       | Basato sullo schema e sovrascritto a ogni esecuzione di `propel:build-forms`
   | BaseFormPropel  | project       | sviluppatore  | Consente la personalizzazione globale dei form Propel
   | sfFormPropel    | Propel plugin | symfony       | Base dei form Propel
   | sfForm          | symfony       | symfony       | Base dei form symfony
@@ -176,7 +176,7 @@ Listato 4-2 - Classe `AuthorForm`
     }
 
 Il Listato 4-3 mostra la classe `BaseAuthorForm`, con i validatori
-ed i widget generati tramite l'introspezione del modello per la
+e i widget generati tramite l'introspezione del modello per la
 tabella `author`.
 
 Listato 4-3 - Classe `BaseAuthorForm`, che rappresenta il form della tabella `author`
@@ -527,7 +527,7 @@ essere sovrascritto esplicitamente dall'utente. Anche se questo campo è
 obbligatorio nello schema, non può esserlo nel form. Per questo motivo
 modifichiamo il validatore e lo rendiamo opzionale, come nel Listato 4-8.
 Personalizzeremo anche il campo `content`, aumentando la sua dimensione e
-forzando l'utente ad inserirvi almeno cinque caratteri.
+forzando l'utente a inserirvi almeno cinque caratteri.
 
 Listato 4-8 - Personalizzare i validatori e i widget
 
@@ -879,10 +879,10 @@ di vita dei form, iniziando dal codice generato dal task `propel:generate-crud`.
 
 ### Valori di default
 
-**Un'istanza Propel è sempre connessa ad un oggetto Propel**. L'oggetto
+**Un'istanza Propel è sempre connessa a un oggetto Propel**. L'oggetto
 Propel collegato appartiene sempre alla classe restituita dal metodo
 `getModelName()`. Ad esempio, il form `AuthorForm` può essere collegato solo
-ad oggetti che appartengono alla classe `Author`. Questo oggetto è o un
+a oggetti che appartengono alla classe `Author`. Questo oggetto è o un
 oggetto vuoto (un'istanza vuota della classe `Author`), oppure l'oggetto
 inviato al costruttore come primo parametro. Dal momento che il costruttore
 di un form "medio" accetta un array di valori come primo parametro, il
@@ -972,7 +972,7 @@ modifica di oggetti della classe `Author`:
 
       * La chiamata a `retrieveByPk()` di conseguenza restituisce `null`
 
-      * L'oggetto `form` quindi è collegato ad un oggetto Propel `Author`
+      * L'oggetto `form` quindi è collegato a un oggetto Propel `Author`
         vuoto
 
       * La chiamata a `$this->form->save()` crea di conseguenza un nuovo
@@ -997,7 +997,7 @@ modifica di oggetti della classe `Author`:
 Quando un form Propel è valido, il metodo `save()` aggiorna l'oggetto
 correlato e lo memorizza nel database. Questo metodo in realtà memorizza
 non solo l'oggetto principale, ma anche gli eventuali oggetti correlati. Ad
-esempio, il form `ArticleForm` aggiorna i tag connessi ad un articolo.
+esempio, il form `ArticleForm` aggiorna i tag connessi a un articolo.
 Essendo la relazione tra le tabelle `article` e `tag` n-n, i tag relativi
 all'articolo sono salvati nella tabella `article_tag` (usando il metodo
 generato `saveArticleTagList()`).
@@ -1037,7 +1037,7 @@ ogni aggiornamento in una transazione.
 Il metodo `save()` aggiorna automaticamente gli oggetti Propel, ma non può
 gestire gli elementi collaterali come l'invio di file.
 
-Vediamo come allegare un file ad ogni articolo. I file sono memorizzati
+Vediamo come allegare un file a ogni articolo. I file sono memorizzati
 nella cartella `web/uploads` e un riferimento al percorso del file viene
 tenuto nel campo `file` della tabella `article`, come mostrato nel Listato 4-24.
 
@@ -1059,7 +1059,7 @@ oggetti, il database e i relativi form:
 >Ricordare che il task `propel:build-all` cancella tutte le tabelle dello
 >schema e le ricrea. I dati presenti nelle tabelle sono quindi
 >sovrascritti. Per questo è importante creare dei dati di test (`fixtures`),
->che si possono ricaricare ad ogni modifica del modello.
+>che si possono ricaricare a ogni modifica del modello.
 
 Il Listato 4-25 mostra come modificare la classe `ArticleForm` per
 collegare un widget e un validatore al campo `file`.
diff --git a/forms/it/08-Internationalisation-and-Localisation.txt b/forms/it/08-Internationalisation-and-Localisation.txt
index 8e29444..824ebaa 100644
--- a/forms/it/08-Internationalisation-and-Localisation.txt
+++ b/forms/it/08-Internationalisation-and-Localisation.txt
@@ -147,7 +147,7 @@ può essere una delle seguenti tre cose:
 
   * una stringa rappresentante un nome funzione, come `my_function`
 
-  * un array con riferimento ad una istanza di una classe e al nome di
+  * un array con riferimento a una istanza di una classe e al nome di
     uno dei suoi metodi, come `array($anObject, 'oneOfItsMethodsName')`
 
   * una istanza `sfCallable`. Questa classe incapsula un PHP callable
@@ -156,7 +156,7 @@ può essere una delle seguenti tre cose:
 >**Note**
 >Un PHP callable è un riferimento a una funzione o all'istanza di un
 >metodo. È anche una variabile PHP che restituisce `true` quando
->passata ad una funzione `is_callable()`.
+>passata a una funzione `is_callable()`.
 
 Facciamo un esempio. Si deve migrare un progetto che ha già il suo
 sistema di internazionalizzazione, fornito dalla classe mostrata nel
diff --git a/forms/it/11-Doctrine-Integration.txt b/forms/it/11-Doctrine-Integration.txt
index eb0dee2..82c8958 100644
--- a/forms/it/11-Doctrine-Integration.txt
+++ b/forms/it/11-Doctrine-Integration.txt
@@ -3,7 +3,7 @@ Capitolo 11 - Integrazione con Doctrine
 
 In un progetto web, la maggior parte dei form è usata per creare o
 modificare oggetti del modello. Questi oggetti sono solitamente
-serializzati in un database grazie ad un ORM. Il sistema di form
+serializzati in un database grazie a un ORM. Il sistema di form
 di symfony offre un livello addizionale per interfacciarsi con
 Doctrine, l'ORM predefinito in symfony, rendendo l'implementazione
 dei form basati su questi oggetti più facile.
@@ -79,7 +79,7 @@ Ecco le relazioni tra le tabelle:
   * Relazione 1-n tra la tabella `article` e la tabella `author`:
     un articolo è scritto da uno e un solo autore
   * Relazione 1-n tra la tabella `article` e la tabella `category`:
-    un articolo appartiene ad una o nessuna categoria
+    un articolo appartiene a una o nessuna categoria
   * Relazione n-n tra le tabelle `article` e `tag`
 
 Generazione delle classi dei form
@@ -141,7 +141,7 @@ coinvolte nella definizione del form `AuthorForm`.
   | **Classe**       | **Package**     | **Per**       | **Descrizione**
   | ---------------- | --------------- | ------------- | ---------------
   | AuthorForm       | project         | sviluppatore  | Sovrascrive il form generato
-  | BaseAuthorForm   | project         | symfony       | Basato sullo schema e sovrascritto ad ogni esecuzione di `doctrine:build-forms`
+  | BaseAuthorForm   | project         | symfony       | Basato sullo schema e sovrascritto a ogni esecuzione di `doctrine:build-forms`
   | BaseFormDoctrine | project         | sviluppatore  | Consente la personalizzazione globale dei form Doctrine
   | sfFormDoctrine   | Doctrine plugin | symfony       | Base dei form Doctrine
   | sfForm           | symfony         | symfony       | Base dei form symfony
@@ -527,7 +527,7 @@ essere sovrascritto esplicitamente dall'utente. Anche se questo campo è
 obbligatorio nello schema, non può esserlo nel form. Per questo motivo
 modifichiamo il validatore e lo rendiamo opzionale, come nel Listato 4-8.
 Personalizzeremo anche il campo `content`, aumentando la sua dimensione e
-forzando l'utente ad inserirvi almeno cinque caratteri.
+forzando l'utente a inserirvi almeno cinque caratteri.
 
 Listato 4-8 - Personalizzare i validatori e i widget
 
@@ -885,10 +885,10 @@ di vita dei form, iniziando dal codice generato dal task `doctrine:generate-crud
 
 ### Valori di default
 
-**Un'istanza Doctrine è sempre connessa ad un oggetto Doctrine**. L'oggetto
+**Un'istanza Doctrine è sempre connessa a un oggetto Doctrine**. L'oggetto
 Doctrine collegato appartiene sempre alla classe restituita dal metodo
 `getModelName()`. Ad esempio, il form `AuthorForm` può essere collegato solo
-ad oggetti che appartengono alla classe `Author`. Questo oggetto è o un
+a oggetti che appartengono alla classe `Author`. Questo oggetto è o un
 oggetto vuoto (un'istanza vuota della classe `Author`), oppure l'oggetto
 inviato al costruttore come primo parametro. Dal momento che il costruttore
 di un form "medio" accetta un array di valori come primo parametro, il
@@ -993,7 +993,7 @@ modifica di oggetti della classe `Author`:
 
       * La chiamata a `find()` di conseguenza restituisce `null`
 
-      * L'oggetto `form` quindi è collegato ad un oggetto Doctrine `Author`
+      * L'oggetto `form` quindi è collegato a un oggetto Doctrine `Author`
         vuoto
 
       * La chiamata a `$this->form->save()` crea di conseguenza un nuovo
@@ -1018,7 +1018,7 @@ modifica di oggetti della classe `Author`:
 Quando un form Doctrine è valido, il metodo `save()` aggiorna l'oggetto
 correlato e lo memorizza nel database. Questo metodo in realtà memorizza
 non solo l'oggetto principale, ma anche gli eventuali oggetti correlati. Ad
-esempio, il form `ArticleForm` aggiorna i tag connessi ad un articolo.
+esempio, il form `ArticleForm` aggiorna i tag connessi a un articolo.
 Essendo la relazione tra le tabelle `article` e `tag` n-n, i tag relativi
 all'articolo sono salvati nella tabella `article_tag` (usando il metodo
 generato `saveArticleTagList()`).
@@ -1058,7 +1058,7 @@ ogni aggiornamento in una transazione.
 Il metodo `save()` aggiorna automaticamente gli oggetti Doctrine, ma non può
 gestire gli elementi collaterali come l'invio di file.
 
-Vediamo come allegare un file ad ogni articolo. I file sono memorizzati
+Vediamo come allegare un file a ogni articolo. I file sono memorizzati
 nella cartella `web/uploads` e un riferimento al percorso del file viene
 tenuto nel campo `file` della tabella `article`, come mostrato nel Listato 4-24.
 
@@ -1080,7 +1080,7 @@ oggetti, il database e i relativi form:
 >Ricordare che il task `doctrine:build-all` cancella tutte le tabelle dello
 >schema e le ricrea. I dati presenti nelle tabelle sono quindi
 >sovrascritti. Per questo è importante creare dei dati di test (`fixtures`),
->che si possono ricaricare ad ogni modifica del modello.
+>che si possono ricaricare a ogni modifica del modello.
 
 Il Listato 4-25 mostra come modificare la classe `ArticleForm` per
 collegare un widget e un validatore al campo `file`.
diff --git a/forms/it/A-Widgets.txt b/forms/it/A-Widgets.txt
index 3924ebe..d2c856e 100644
--- a/forms/it/A-Widgets.txt
+++ b/forms/it/A-Widgets.txt
@@ -1067,7 +1067,7 @@ all'utente di cercare date vuote.
 ~`sfWidgetFormSchema`~
 ----------------------
 
-`sfWidgetFormSchema` rappresenta un widget composo da più campi.
+`sfWidgetFormSchema` rappresenta un widget composto da più campi.
 Un campo è semplicemente un widget con un nome:
 
     [php]
diff --git a/forms/it/B-Validators.txt b/forms/it/B-Validators.txt
index cb822ed..de507cc 100644
--- a/forms/it/B-Validators.txt
+++ b/forms/it/B-Validators.txt
@@ -214,7 +214,7 @@ ed eredita da `sfValidatorRegex`.
 *Validatore schema**: No
 
 Il validatore `sfValidatorUrl` può validare indirizzi, URL HTTP
-ed URL FTP. Eredita da `sfValidatorRegex`.
+e URL FTP. Eredita da `sfValidatorRegex`.
 
 | Opzione     | Errore    | Descrizione
 | ----------- | --------- | -----------
@@ -277,7 +277,7 @@ di tipo booleano e restituisce i valori `true` o `false`.
 *Validatore schema**: No
 
 Il validatore `sfValidatorChoice` controlla se i valori inseriti
-appartengono ad una lista di valori definiti.
+appartengono a una lista di valori definiti.
 
 | Opzione    | Errore | Descrizione
 | ---------- | ------ | -----------
@@ -301,7 +301,7 @@ i valori di input così come sono.
 
 *Validatore schema**: No
 
-Il validatore `sfValidatorCallback` delega il controllo ad un callback
+Il validatore `sfValidatorCallback` delega il controllo a un callback
 di PHP.
 
 Al callback sono passati come parametri l'istanza del validatore, i valori
@@ -507,7 +507,7 @@ Il costruttore di `sfValidatorAnd` accetta una lista di validatori come primo pa
 
 Di default, il validatore lancia un array di messaggi d'errore lanciati da tutti
 i validatori inclusi. Può inoltre lanciare un singolo messaggio d'errore se il messaggio
-d'errore `invalid` è impostato ad una stringa non vuota, come mostrato nell'esempio
+d'errore `invalid` è impostato a una stringa non vuota, come mostrato nell'esempio
 precedente.
 
 | Opzione         | Errore | Descrizione
@@ -541,7 +541,7 @@ Il costruttore `sfValidatorOr` accetta una lista di validatori come primo parame
 
 Di default il validatore lancia un array di messaggi d'errore lanciati da tutti i
 validatori inclusi. Può inoltre lanciare un singolo messaggio d'errore se il messaggio
-d'errore `invalid` è impostato ad una stringa non vuota, come mostrato nell'esempio
+d'errore `invalid` è impostato a una stringa non vuota, come mostrato nell'esempio
 precedente.
 
 La lista di validatori inclusi può essere inoltre gestita usando i metodi
@@ -644,7 +644,7 @@ Il messaggio di errore `invalid` accetta i seguenti valori: `%left_field%`,
 *Validatore schema**: Sì
 
 Il validatore `sfValidatorSchemaFilter` converte un validatore di tipo non-schema
-ad un validatore di tipo schema. A volte è utile nell'ambito dei post validatori:
+a un validatore di tipo schema. A volte è utile nell'ambito dei post validatori:
 
     [php]
     $v = new sfValidatorSchema();
diff --git a/reference/it/01-Introduction.markdown b/reference/it/01-Introduction.markdown
index 000b9a0..050f584 100644
--- a/reference/it/01-Introduction.markdown
+++ b/reference/it/01-Introduction.markdown
@@ -6,7 +6,7 @@ per aumentare la propria velocità ed efficienza come sviluppatore web.
 Il framework include nella sua distribuzione molte caratteristiche utili,
 che aiutano a concentrarsi sulla logica della propria applicazione,
 piuttosto che sull'implementazione, ad esempio per l'ennesimo paginatore
-ad oggetti o per l'ennesimo livello di astrazione del database. Tuttavia,
+a oggetti o per l'ennesimo livello di astrazione del database. Tuttavia,
 questo ha anche un costo; per imparare tutte le caratteristiche disponibili
 e tutte le possibilità di configurazione potrebbe non bastare una giornata.
 
@@ -20,7 +20,7 @@ alle proprie domande, in poco tempo. Il libro *Guida di Riferimento a symfony*
 si prefigge lo scopo di fornire una guida del genere. È un libro
 complementare a *Symfony in pratica*. È un libro da tenere con sé ogni
 volta che si sviluppa con symfony. Questo libro è il modo più rapido per
-trovare ogni possibile configurazione, grazie ad un indice molto dettagliato,
+trovare ogni possibile configurazione, grazie a un indice molto dettagliato,
 un glossario, riferimenti incrociati nei capitoli, tabelle e molto altro.
 
 Pur essendo lo sviluppatore capo di symfony, io stesso uso questo libro di
diff --git a/reference/it/02-YAML.markdown b/reference/it/02-YAML.markdown
index 36eb285..5ec1ee8 100644
--- a/reference/it/02-YAML.markdown
+++ b/reference/it/02-YAML.markdown
@@ -265,7 +265,7 @@ prima dell'interpretazione:
       versione: "<?php echo file_get_contents('1.1/VERSION') ?>"
 
 Occorre fare attenzione a non scombinare l'indentazione. Tenete a mente le
-seguenti semplici regole quando aggiungete codice PHP ad un file YAML:
+seguenti semplici regole quando aggiungete codice PHP a un file YAML:
 
 
  * Le istruzioni `<?php ?>` devono sempre iniziare la riga o essere incluse in
diff --git a/reference/it/04-Settings.markdown b/reference/it/04-Settings.markdown
index 5af2ae4..cf70c1d 100644
--- a/reference/it/04-Settings.markdown
+++ b/reference/it/04-Settings.markdown
@@ -12,7 +12,7 @@ Come anticipato nell'introduzione il file `settings.yml` è
 [consapevole dell'ambiente](#chapter_03_consapevolezza_dell_ambiente) 
 e beneficia del [**meccanismo di configurazione a cascata**](#chapter_03_configurazione_a_cascata).
 
-Ogni sezione dedicata ad un ambiente ha due sottosezioni: `.actions` e `.settings`.
+Ogni sezione dedicata a un ambiente ha due sottosezioni: `.actions` e `.settings`.
 Tutte le impostazioni vanno inserite nella sottosezione `.settings`, eccezion 
 fatta per le azioni predefinite da visualizzare per alcune pagine comuni.
 
@@ -92,7 +92,7 @@ L'azione `error_404` viene eseguita quando deve essere visualizzata una pagina 4
 ### ~`login`~
 
 L'azione `login` viene eseguita quando un utente non autenticato cerca di accedere
-ad una pagina protetta.
+a una pagina protetta.
 
 ### ~`secure`~
 
@@ -101,7 +101,7 @@ L'azione `secure` viene eseguita quando un utente non ha le credenziali richiest
 ### ~`module_disabled`~
 
 L'azione `module_disabled` viene eseguita quando un utente invia una richiesta
-ad un modulo disabilitato.
+a un modulo disabilitato.
 
 La sottosezione `.settings`
 ---------------------------
@@ -163,7 +163,7 @@ l'inglese o lingue europee.
 L'impostazione `csrf_secret` specifica una chiave univoca di sicurezza per 
 l'applicazione. Se non è impostata a `false`, attiva la protezione CSRF per 
 tutti i form generati dal framework dei form. Questa impostazione è utilizzata anche 
-dall'helper `link_to()` quando c'è la necessità di convertire un link ad un form
+dall'helper `link_to()` quando c'è la necessità di convertire un link a un form
 (per simulare un metodo HTTP `DELETE` per esempio).
 
 È vivamente consigliato di cambiare il valore predefinito con una chiave segreta
@@ -237,7 +237,7 @@ L'impostazione `cache` abilita o meno la cache dei template.
 
 ### ~`etag`~
 
-*Predefinito*: `true` ad esclusione degli ambienti `dev` e `test`
+*Predefinito*: `true`, tranne per gli ambienti `dev` e `test`
 
 L'impostazione `etag` abilita e disabilita la generazione automatica degli header 
 HTTP `ETag`. L'ETag generato da symfony è un semplice md5 del contenuto della 
diff --git a/reference/it/05-Factories.markdown b/reference/it/05-Factories.markdown
index 889a208..e963dd9 100644
--- a/reference/it/05-Factories.markdown
+++ b/reference/it/05-Factories.markdown
@@ -305,7 +305,7 @@ sulle classi di trasporto built-in e i loro differenti parametri.
 ### ~`path_info_array`~
 
 L'opzione `path_info_array` definisce l'array PHP globale che sarà usato per recuperare informazioni. 
-In alcune configurazioni il valore predefinito potrebbe essere cambiato da `SERVER` ad `ENV`.
+In alcune configurazioni il valore predefinito potrebbe essere cambiato da `SERVER` a `ENV`.
 
 ### ~`path_info_key`~
 
@@ -355,7 +355,7 @@ cambiamenti.
 L'opzione `send_http_headers` specifica quando deve essere inviato un
 header di risposta insieme al contenuto della risposta. Questa opzione è particolarmente 
 comoda per fare test, in quanto gli header sono inviati tramite la funzione PHP 
-`header()`, che invia un warning se si sta provando ad inviare header dopo qualche tipo
+`header()`, che invia un warning se si sta provando a inviare header dopo qualche tipo
 di output.
 
 ### ~`charset`~
@@ -395,7 +395,7 @@ altrimenti usa `HTTP/1.0`.
 
 L'opzione `timeout` definisce il timeout per l'autenticazione utente.
 Non è correlata al timeout della sessione. Il valore predefinito rimuove l'autenticazione
-ad un utente dopo 30 minuti di inattività.
+a un utente dopo 30 minuti di inattività.
 
 Questa impostazione è usata solo dalle classi user che ereditano dalla classe base 
 `sfBasicSecurityUser`, come nel caso della classe generata dal sistema `myUser`.
diff --git a/reference/it/06-Admin-Generator.markdown b/reference/it/06-Admin-Generator.markdown
index 4268bbf..ad727b2 100644
--- a/reference/it/06-Admin-Generator.markdown
+++ b/reference/it/06-Admin-Generator.markdown
@@ -685,7 +685,7 @@ contenente un sottoinsieme di campi del form.
 
 >**CAUTION**
 >Tutti i campi definiti nel modello del form devono essere presenti nell'opzione
->`display`. Se così non fosse, questo potrebbe portare ad inaspettati errori di validazione
+>`display`. Se così non fosse, questo potrebbe portare a inaspettati errori di validazione
 
 ### ~`class`~
 
diff --git a/reference/it/08-Security.markdown b/reference/it/08-Security.markdown
index e46767c..3cda22f 100644
--- a/reference/it/08-Security.markdown
+++ b/reference/it/08-Security.markdown
@@ -39,7 +39,7 @@ nel seguente ordine:
   * la configurazione predefinita dell'applicazione (sotto la chiave `default`).
 
 Le stesse regole di precedenza sono usate per determinare le credenziali necessarie per
-accedere ad una azione.
+accedere a una azione.
 
 >**NOTE**
 >Il file di configurazione `security.yml` è memorizzato nella cache come file PHP; il
@@ -60,7 +60,7 @@ Con l'impostazione della chiave ~`is_secure`~ su `true` nel file dell'applicazio
  `security.yml`, l'intera applicazione richiederà l'autenticazione per tutti gli utenti.
 
 >**NOTE**
->Quando un utente non autenticato prova ad accedere ad una azione messa in sicurezza, symfony
+>Quando un utente non autenticato prova ad accedere a una azione messa in sicurezza, symfony
 >inoltra la richiesta all'azione `login` configurata in `settings.yml`.
 
 Per modificare i requisiti di autenticazione di un modulo, creare un file `security.yml`
diff --git a/reference/it/11-App.markdown b/reference/it/11-App.markdown
index 206928c..2fe1505 100644
--- a/reference/it/11-App.markdown
+++ b/reference/it/11-App.markdown
@@ -4,7 +4,7 @@ Il file di configurazione app.yml
 Il framework symfony mette a disposizione uno specifico file di configurazione 
 per le impostazione di un'applicazione, il file `app.yml`.
 
-Questo file YAML può contenere ogni tipo di impostazione che può servire ad una 
+Questo file YAML può contenere ogni tipo di impostazione che può servire a una 
 specifica applicazione. Nel codice, queste impostazioni sono disponibili tramite
 la classe globale `sfConfig` e le chiavi hanno come prefisso la stringa `app_`:
 
@@ -13,7 +13,7 @@ la classe globale `sfConfig` e le chiavi hanno come prefisso la stringa `app_`:
 
 Tutte le impostazioni hanno il prefisso `app_`, perché la classe `sfConfig` 
 permette l'accesso anche alle [impostazioni di symfony](#chapter_03_sub_impostazioni_della_configurazione)
-ed alle [cartelle del progetto](#chapter_03_sub_le_cartelle).
+e alle [cartelle del progetto](#chapter_03_sub_le_cartelle).
 
 Come già visto nell'introduzione, il file `app.yml` ha la 
 [consapevolezza dell'ambiente](#chapter_03_consapevolezza_dell_ambiente) e 
@@ -21,7 +21,7 @@ beneficia della [configurazione a cascata](#chapter_03_configurazione_a_cascata)
 
 Il file di configurazione `app.yml` è un ottimo posto in cui definire le impostazioni
 che cambiano in base all'ambiente (una chiave API per esempio) o le impostazioni
-che possono mutare nel tempo (si pensi ad un indirizzo email). È inoltre il posto
+che possono mutare nel tempo (si pensi a un indirizzo email). È inoltre il posto
 migliore dove definire le impostazioni che necessitano di essere modificate da
 qualcuno che non deve necessariamente conoscere symfony o PHP 
 (un amministratore di sistema, per esempio).
diff --git a/reference/it/14-Other-Configuration-Files.markdown b/reference/it/14-Other-Configuration-Files.markdown
index 10eadf8..8e1bc29 100644
--- a/reference/it/14-Other-Configuration-Files.markdown
+++ b/reference/it/14-Other-Configuration-Files.markdown
@@ -128,7 +128,7 @@ uniti in un unico grosso file nell'ambiente `prod`, per velocizzare il tempo
 necessario a symfony per caricare. Per impostazione predefinita, le principali classi del core di symfony
 sono definite in questo file di configurazione. Se l'applicazione si basa su alcune classi
 che necessitano di essere caricate per ogni richiesta, è possibile creare un file di
-configurazione `core_compile.yml` nel progetto o applicazione e aggiungerli ad esso. Questo è
+configurazione `core_compile.yml` nel progetto o applicazione e aggiungerli a esso. Questo è
 un estratto della configurazione predefinita:
 
     [yml]
diff --git a/reference/it/15-Events.markdown b/reference/it/15-Events.markdown
index f7c5fa6..5ceae8e 100644
--- a/reference/it/15-Events.markdown
+++ b/reference/it/15-Events.markdown
@@ -291,7 +291,7 @@ si può aggiungere un metodo alla classe senza usare l'ereditarietà.
 
 L'evento `context.load_factories` è notificato una volta a richiesta
 dall'oggetto `sfContext`, subito dopo che tutti i factory sono stati
-inizializzati. È il primo evento ad essere notificato con tutte le
+inizializzati. È il primo evento a essere notificato con tutte le
 classi principali inizializzate.
 
 `controller`
@@ -553,7 +553,7 @@ dalla CLI con il task `cache:clear`.
 
 L'evento `template.filter_parameters` è notificato prima che la vista di un
 file sia resa. Ascoltando questo evento, si può accedere e manipolare le
-variabili passate ad un template.
+variabili passate a un template.
 
 `user`
 ------
diff --git a/reference/it/16-Tasks.markdown b/reference/it/16-Tasks.markdown
index 413cb98..1b6612e 100644
--- a/reference/it/16-Tasks.markdown
+++ b/reference/it/16-Tasks.markdown
@@ -1427,7 +1427,7 @@ il progetto:
 
     ./symfony generate:project blog --installer=./installer.php
 
-Opzionalmente si può includere un secondo argomento `autore` per specificare qual'è
+Opzionalmente si può includere un secondo argomento `autore` per specificare qual è
 il nome da utilizzare come autore quando symfony genera nuove classi:
 
     ./symfony generate:project blog "Jack Doe"

From 762462d7d371b413b0fffab6db7006f575153496 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Mon, 6 Sep 2010 13:13:14 +0200
Subject: [PATCH 08/10] [gentle][it] corrections on chap. 11

---
 gentle-introduction/it/11-Emails.markdown | 190 +++++++++++-----------
 1 file changed, 94 insertions(+), 96 deletions(-)

diff --git a/gentle-introduction/it/11-Emails.markdown b/gentle-introduction/it/11-Emails.markdown
index 3910308..4b46d71 100644
--- a/gentle-introduction/it/11-Emails.markdown
+++ b/gentle-introduction/it/11-Emails.markdown
@@ -14,24 +14,24 @@ Introduzione
 ------------
 
 La gestione delle email in symfony ruota intorno all'oggetto mailer. Come 
-altri oggetti del nocciolo di symfony, il mailer è una factory. Esso è configurato nel
+altri oggetti del nocciolo di symfony, il mailer è un factory. Esso è configurato nel
 file di configurazione `factories.yml` ed è sempre accessibile attraverso l'istanza del contesto:
 
     [php]
     $mailer = sfContext::getInstance()->getMailer();
 
 >**TIP**
->A differenza delle altre factory, il mailer viene caricato e inizializzato su richiesta. Se
+>A differenza degli altri factory, il mailer viene caricato e inizializzato su richiesta. Se
 > non venisse utilizzato, non si avranno impatti sulle performance o altri effetti collaterali.
 
-Questo tutotial spiega come Swift Mailer sia integrato all'interno di symfony. Se si volesse
+Questa guida spiega come Swift Mailer sia integrato all'interno di symfony. Se si volessero
 approfondire tutti i particolari della libreria Swfit Mailer, ci si deve riferire alla
 [documentazione](http://www.swiftmailer.org/docs) dedicata.
 
-Invio di un'Email dalla Action
+Invio di un'email dall'azione
 -----------------------------
 
-Per ottenere l'istanza del mailer nella action basta semplicemente invocare il metodo scorciatoia
+Per ottenere l'istanza del mailer nell'azione, basta semplicemente invocare il metodo scorciatoia
 `getMailer()`:
 
     [php]
@@ -39,7 +39,7 @@ Per ottenere l'istanza del mailer nella action basta semplicemente invocare il m
 
 ### Modalità veloce
 
-L'invio di un'email è semplice utilizzando il metodo ~`sfAction::composeAndSend()`~:
+L'invio di un'email è semplice, utilizzando il metodo ~`sfAction::composeAndSend()`~:
 
     [php]
     $this->getMailer()->composeAndSend(
@@ -63,31 +63,30 @@ o un array:
     $address = 'fabien@example.com';
     $address = array('fabien@example.com' => 'Fabien Potencier');
 
-Ovviamente è possibile inviare un'email a diverse persone in una volta sola passando un array
-di email come secondo argomento del metodo:
+Ovviamente è possibile inviare un'email a diverse persone in una volta sola, passando un array
+di email come secondo parametro del metodo:
 
     [php]
     $to = array(
-      'foo@example.com',
-      'bar@example.com',
+      'pippo@example.com',
+      'pluto@example.com',
     );
     $this->getMailer()->composeAndSend('from@example.com', $to, 'Subject', 'Body');
 
     $to = array(
-      'foo@example.com' => 'Mr Foò,
-      'bar@example.com' => 'Miss Bar',
+      'pippo@example.com' => 'Pippo',
+      'pluto@example.com' => 'Pluto',
     );
     $this->getMailer()->composeAndSend('from@example.com', $to, 'Subject', 'Body');
 
 ### Modalità flessibile
 
 Se si desiderasse maggior flessibilità è possibile utilizzare il metodo ~`sfAction::compose()`~
-per creare il messaggio, personalizzarlo nella maniera più appropiata e eventualmente inviarlo
-Ciò è utile, per esempio, qualora si avesse bisogno di aggiungere un allegato come mostrato di seguito
-~attachment|email attachment~ as shown below:
+per creare il messaggio, personalizzarlo nella maniera più appropriata e eventualmente inviarlo
+Ciò è utile, per esempio, qualora si avesse bisogno di aggiungere un ~allegato~, come mostrato di seguito:
 
     [php]
-    //creazione dell'oggetto messaggio
+    // creazione dell'oggetto messaggio
     $message = $this->getMailer()
       ->compose('from@example.com', 'fabien@example.com', 'Subject', 'Body')
       ->attach(Swift_Attachment::fromPath('/path/to/a/file.zip'))
@@ -98,7 +97,7 @@ Ciò è utile, per esempio, qualora si avesse bisogno di aggiungere un allegato
 
 ### Modalità più raffinata
 
-E' possibile anche creare un messaggio direttamente per aver maggior flessibilità:
+È possibile anche creare un messaggio direttamente, per aver maggior flessibilità:
 
     [php]
     $message = Swift_Message::newInstance()
@@ -119,16 +118,16 @@ E' possibile anche creare un messaggio direttamente per aver maggior flessibilit
 
 ### Utilizzo della vista di symfony
 
-L'invio delle email dalla action permette di far leva in modo piuttosto semplice sulla potenza
+L'invio delle email dall'azione permette di far leva in modo piuttosto semplice sulla potenza
 dei partial e component:
 
     [php]
-    $message->setBody($this->getPartial('partial_namè, $arguments));
+    $message->setBody($this->getPartial('partial_name', $arguments));
 
 Configurazione
--------------
+--------------
 
-Come gli altri oggetti factory, il mailer può essere configurato in
+Come gli altri oggetti factory, il mailer può essere configurato
 nel file di configurazione `factories.yml'. La configurazione predefinita è la seguente:
 
     [yml]
@@ -162,25 +161,25 @@ agli ambienti `prod`, `env` e `test`:
         param:
           delivery_strategy: none
 
-Strategia di Invio
----------------------
+Strategia di invio
+------------------
 
 Una delle più utili caratteristiche dell'integrazione di Swift Mailer con symfony è
 la strategia d'invio. Essa permette di indicare a symfony
 come inviare i messaggi email ed è configurata tramite il il parametro ~`delivery_strategy`~
-del file `factories.yml`. La strategia cambia il comportamento ' 
-del metodo ~`send()`|`sfMailer::send()`~ . Sono disponibili quattro diverse strategie predefinite
+del file `factories.yml`. La strategia cambia il comportamento
+del metodo ~`send()`|`sfMailer::send()`~. Sono disponibili quattro diverse strategie predefinite,
 che dovrebbero soddisfare esigenze comuni:
 
  * `realtime`:       I messaggi vengono inviati in tempo reale.
- * `single_address`: I messaggi vengono inviati ad un singolo indirizzo.
+ * `single_address`: I messaggi vengono inviati a un singolo indirizzo.
  * `spool`:          I messaggi vengono collocati in una coda.
  * `none`:           I messaggi vengono semplicemente ignorati.
 
 ### Strategia ~`realtime`~
 
-La strategia `realtime` è la strategia predefinita, ed è la modalità più semplice
-da configurare in quanto non c'è bisogno di nessuno intervento da parte dello sviluppatore.
+La strategia `realtime` è la strategia predefinita ed è la modalità più semplice
+da configurare, in quanto non c'è bisogno di nessuno intervento da parte dello sviluppatore.
 
 I messaggi email vengono inviati attraverso il mezzo di trasporto configurato nella sezione `transport`
 del file di configurazione `factories.yml` (vedere la prossima sezione per avere più informazioni
@@ -188,15 +187,15 @@ riguardanti la configurazione del mezzo di trasporto delle mail).
 
 ### Strategia ~`single_address`~
 
-Con la strategia ~`single_address`~ , tutti i messaggi vengono inviati ad un singolo indirizzo 
+Con la strategia ~`single_address`~ , tutti i messaggi vengono inviati a un singolo indirizzo 
 configurato tramite il parametro `delivery_address`.
 
 Questa strategia risulta veramente utile in un ambiente di sviluppo per evitare l'invio
 di messaggi a utenti reali, permettendo comunque allo sviluppatore di controllare
-come la mail appaia effettivamente in un client email.
+come la mail appaia effettivamente in un programma di posta.
 
 >**TIP**
->Se si avesse bisogno di verificare i destinatari `to`, `cc`, e `bcc` essi sono
+>Se si avesse bisogno di verificare i destinatari `to`, `cc` e `bcc`, essi sono
 >disponibili come valori dei seguenti header: `X-Swift-To`, `X-Swift-Cc`, e `X-Swift-Bcc`.
 
 I messaggi email vengono inviati con lo stesso mezzo di trasporto utilizzato nella
@@ -210,7 +209,7 @@ Con la strategia `spool` i messaggi vengono memorizzati in una coda.
 Questa è la miglior strategia per un ambiente di produzione, in quanto una richiesta web
 non deve attendere che la mail sia inviata.
 
-La class di `spool` viene configurata attraverso il parametro ~`spool_class`~. Symfony propone tre diverse alternative:
+La classe di `spool` viene configurata attraverso il parametro ~`spool_class`~. Symfony propone tre diverse alternative:
 
  * ~`Swift_FileSpool`~: I messaggi vengono memorizzati su filesystem.
 
@@ -223,13 +222,13 @@ vengono passati al costruttore della classe stessa. Di seguito vengono mostrate
 
  * `Swift_FileSpool`:
 
-    * Percorso assoluto della directory nella quale viene memorizzata la coda dei messaggi.
+    * Percorso assoluto della cartella in cui viene memorizzata la coda dei messaggi.
 
  * `Swift_DoctrineSpool`:
 
-    * Il modello di Doctrine utilizzato per memorizzare i messaggi (`MailMessage` è quello predefinito)
+    * Il modello di Doctrine utilizzato per memorizzare i messaggi (`MailMessage` come predefinito)
 
-    * Il nome della colonna utilizzata per memorizzare il messaggio (`message` come valore predefinito)
+    * Il nome della colonna utilizzata per memorizzare il messaggio (`message` come predefinito)
 
     * Il metodo da chiamare per ottenere il messaggio da inviare (opzionale). 
       Riceve le opzione della coda come argomento.
@@ -295,7 +294,7 @@ con lo stesso mezzo di trasporto utilizzato dalla strategia `realtime`.
 
 >**TIP**
 >Il task `project:send-emails` può essere invocato su qualsiasi macchina,
->non neccesariamente dalla macchina che ha creato il messaggio. Ciò funziona perchè
+>non necessariamente dalla macchina che ha creato il messaggio. Ciò funziona perché
 >tutto viene memorizzato nell'oggetto messaggio, anche gli eventuali file allegati.
 
 -
@@ -320,7 +319,7 @@ Il commando appena mostrato smetterà di inviare messaggi dopo che ne avrà invi
 e dopo 20 secondi.
 
 Anche quando viene utilizzata la strategia `spool` potrebbe essere utile
-inviare un messaggio immediatamente senza memorzzarlo in una coda. Questo è possibile
+inviare un messaggio immediatamente senza memorizzarlo in una coda. Questo è possibile
 utilizzando il metodo speciale del mailer `sendNextImmediately()`:
 
     [php]
@@ -338,15 +337,15 @@ avrà effetto soltanto sul successivo messaggio da inviare.
 
 Questa strategia è utile in un ambiente di sviluppo in modo da evitare che le 
 mail vengano inviate agli utenti reali. I messaggi sono disponibili nella web debug toolbar
-(maggiori informazione nella sezione sottostante nella quale viene spiegato il panello mailer della 
+(maggiori informazione nella sezione sottostante nella quale viene spiegato il pannello mailer della 
 web debug toolbar).
 
-E' anche la miglior strategia per l'ambiente di test, dove
+È anche la miglior strategia per l'ambiente di test, dove
 l'oggetto `sfTesterMailer` permette di poter effettuare un'introspezione dei messaggi
-senza doverli effettivamente inviare (maggiori informazioni nella sezione sottostante dedicata al testing).
+senza doverli effettivamente inviare (maggiori informazioni nella sezione sottostante dedicata ai test).
 
-Il mezzo di trasporto delle Mail
-------------------
+Il mezzo di trasporto delle mail
+--------------------------------
 
 I messaggi mail sono inviati da un mezzo di trasporto. Esso può essere configurato
 nel file di configurazione `factories.yml`, e i valori predefiniti utilizzano
@@ -372,67 +371,67 @@ Swift Mailer fornisce tre diversi mezzi di trasporto:
 
 >**TIP**
 >La sezione ["Transport Types"](http://swiftmailer.org/docs/transport-types)
->della documentazione ufficale di Swift Mailer descrive tutto quello che c'è da sapere
+>della documentazione ufficiale di Swift Mailer descrive tutto quello che c'è da sapere
 >riguardo alle classi di trasporto e i diversi parametri.
 
-Invio di un Email da un Task
-----------------------------
+Invio di una email da un task
+-----------------------------
 
-Inviare email da un task è simile all'invio di una mail da una action
+Inviare email da un task è simile all'invio di una mail da un'azione,
 in quanto anche il sistema alla base dei task mette a disposizione un metodo `getMailer()`.
 
-Nel momento in cui viene creato il mailer, il sistema dei task si appoggia alla configurazione corrente
-Quindi se si volesse utilizzare una configurazione di una pecifica applicazione
+Nel momento in cui viene creato il mailer, il sistema dei task si appoggia alla configurazione corrente.
+Quindi, se si volesse utilizzare una configurazione di una specifica applicazione,
 si deve specificare l'opzione `--application` (riferirsi al capitolo sui task per maggiori informazioni).
 
-Da notare che il task utilizza la stessa configurazione dei controllori. Quindi se
-si volesse forzare l'invio quando viene utilizzata la strategia `spool` si deve utilizzare `sendNextImmediately()`:
+Da notare che il task utilizza la stessa configurazione dei controllori. Quindi, se
+si volesse forzare l'invio quando viene utilizzata la strategia `spool`, si deve utilizzare `sendNextImmediately()`:
 
     [php]
     $this->getMailer()->sendNextImmediately()->send($message);
 
-Debugging
----------
+Debug
+-----
 
 Solitamente eseguire il debug dell'invio delle mail è sempre stato un incubo. Con symfony invece tale 
 operazione è molto semplice, grazie alla ~web debug toolbar~.
 
-E' possibile controllare direttamente dal browser in modo rapido e semplice 
+È possibile controllare direttamente dal browser in modo rapido e semplice 
 quanti messaggi sono stati inviati dalla action corrente:
 
-![Emails in the Web Debug Toolbar](http://www.symfony-project.org/images/more-with-symfony/emails_wdt.png "Emails in the Web Debug Toolbar")
+![Email nella Web Debug Toolbar](http://www.symfony-project.org/images/more-with-symfony/emails_wdt.png "Email nella Web Debug Toolbar")
 
 Se si clicca sull'icona della mail vengono mostrati i messaggi inviati nella loro forma grezza:
 
-![Emails in the Web Debug Toolbar - details](http://www.symfony-project.org/images/more-with-symfony/emails_wdt_details.png "Emails in the Web Debug Toolbar - details")
+![Email nella Web Debug Toolbar - dettagli](http://www.symfony-project.org/images/more-with-symfony/emails_wdt_details.png "Email nella Web Debug Toolbar - dettagli")
 
 >**NOTE**
 >Tutte le volte che un'email viene inviata, symfony aggiunge un messaggio nei log.
 
-Testing
--------
+Test
+----
 
-L'integrazione non sarebbe completa senza una modalità di testing dei messaggi email.
-Symfony registra in modo predefinito un mailer tester
-(~`sfMailerTester`~)  per facilitare il test delle mail nei test funzionali.
+L'integrazione non sarebbe completa senza una modalità di test dei messaggi email.
+Symfony registra in modo predefinito un tester mailer
+(~`sfMailerTester`~) per facilitare il test delle mail nei test funzionali.
 
 Il metodo ~`hasSent()`~ testa il numero di messaggi inviati durante la richiesta corrente:
 
     [php]
     $browser->
-      get('/foò)->
+      get('/pippo')->
       with('mailer')->
         hasSent(1)
     ;
 
-Il codice appena mostrato controlla che l'URL `/foo` invii soltanto un'email.
+Il codice appena mostrato controlla che l'URL `/pippo` invii soltanto una email.
 
 Ogni email inviata può essere testata con l'aiuto dei metodi ~`checkHeader()`~ 
 e ~`checkBody()`~ :
 
     [php]
     $browser->
-      get('/foò)->
+      get('/pippo')->
       with('mailer')->begin()->
         hasSent(1)->
         checkHeader('Subject', '/Subject/')->
@@ -443,20 +442,20 @@ e ~`checkBody()`~ :
 Il secondo argomento di `checkHeader()` e il primo argomento di `checkBody()`
 può essere uno dei seguenti:
 
- * una stringa per contollare un esatta corrispondenza;
+ * una stringa per controllare un'esatta corrispondenza;
  
  * un'espressione regolare per controllarne i valori;
 
  * un'espressione regolare negativa (un'espressione regolare che inizi con `!`)
    per controllare che il valore non corrisponda.
 
-Come impostazione predefinita i controlli vengono fatti sul primo messaggio inviato. Se venissero inviati
-ulteriori messaggi è possibile decidere quale messaggio debba essere testato con 
+Come impostazione predefinita, i controlli vengono fatti sul primo messaggio inviato. Se venissero inviati
+ulteriori messaggi, è possibile decidere quale messaggio debba essere testato con 
 il metodo ~`withMessage()`~ :
 
     [php]
     $browser->
-      get('/foò)->
+      get('/pippo')->
       with('mailer')->begin()->
         hasSent(2)->
         withMessage('foo@example.com')->
@@ -465,8 +464,8 @@ il metodo ~`withMessage()`~ :
       end()
     ;
 
-Il metodo `withMessage()` accetta un destinatario come primo argomento. Inoltre accetta
-un secondo argomento per indicare quale messaggio si vuole testare qualora ci fossero diversi
+Il metodo `withMessage()` accetta un destinatario come primo parametro. Inoltre accetta
+un secondo parametro per indicare quale messaggio si vuole testare, qualora ci fossero diversi
 messaggi inviati allo stesso destinatario.
 
 Infine il metodo ~`debug()`~ fornisce un dump dei messaggi inviati per poter analizzare 
@@ -474,19 +473,19 @@ eventuali problemi se un test fallisse:
 
     [php]
     $browser->
-      get('/foò)->
+      get('/pippo')->
       with('mailer')->
       debug()
     ;
 
-Messaggi Email come Classi
--------------------------
+Messaggi email come classi
+--------------------------
 
 Nell'introduzione di questo capitolo è stato mostrato come inviare email
-da una action. Questo è probabilmente la maniera più semplice di inviare email in 
+da un'azione. Questo è probabilmente la maniera più semplice di inviare email in 
 un'applicazione symfony e probabilmente la migliore quando si vuole inviare pochi e semplici messaggi.
 
-Ma quando l'applicazione neccesita di poter gestire un gran numero di differenti messaggi email,
+Ma quando l'applicazione necessita di poter gestire un gran numero di differenti messaggi email,
 si dovrebbe utilizzare una strategia diversa.
 
 >**NOTE**
@@ -511,13 +510,13 @@ Dato che i messaggi sono semplici oggetti PHP, l'ovvia modalità per gestire i m
       }
     }
 
-L'invio di messaggi da una action, o da altre punti dell'applicativo, comporta 
-semplicemente l'inizializzazione  della appropiata classe del messaggio
+L'invio di messaggi da un'azione o da altre punti dell'applicativo comporta 
+semplicemente l'inizializzazione  della appropriata classe del messaggio
 
     [php]
     $this->getMailer()->send(new ProjectConfirmationMessage());
 
-Ovviamente può risultare conveniente aggiungenre una classe base per centralizzare gli header condivisi come
+Ovviamente può risultare conveniente aggiungere una classe base per centralizzare gli header condivisi come
 `From` o aggiungere una firma comune:
 
     [php]
@@ -565,9 +564,9 @@ come argomenti al costruttore:
     }
 
 Destinatari
--------
+-----------
 
-### Invio di Email con ~Gmail~
+### Invio di email con ~Gmail~
 
 Se non si avesse a disposizione un server SMTP ma si disponesse di un account Gmail, è possibile
 impiegare la seguente configurazione per utilizzare i server di Google per l'invio e archiviazione dei messaggi:
@@ -579,19 +578,18 @@ impiegare la seguente configurazione per utilizzare i server di Google per l'inv
         host:       smtp.gmail.com
         port:       465
         encryption: ssl
-        username:   your_gmail_username_goes_here
-        password:   your_gmail_password_goes_here
+        username:   il_proprio_nome_utente_di_gmail
+        password:   la_propria_password_di_gmail
 
-E' sufficiente sostituire `username` e `password` con le proprie credenziale di Gmail e il gioco è fatto.
+È sufficiente sostituire `username` e `password` con le proprie credenziale di Gmail e il gioco è fatto.
 
 ### Personalizzazione dell'oggetto Mailer
 
-Se non bastasse la configurazione del mailer attraverso il file di configurazione `factories.yml`
+Se non bastasse la configurazione del mailer attraverso il file di configurazione `factories.yml`,
 è possibile utilizzare e mettersi in ascolto dell'evento  ~`mailer.configure`~ e
 personalizzare di conseguenza il mailer.
 
 
-
     [php]
     class ProjectConfiguration extends sfProjectConfiguration
     {
@@ -600,7 +598,7 @@ personalizzare di conseguenza il mailer.
         // ...
 
         $this->dispatcher->connect(
-          'mailer.configurè,
+          'mailer.configure',
           array($this, 'configureMailer')
         );
       }
@@ -609,13 +607,13 @@ personalizzare di conseguenza il mailer.
       {
         $mailer = $event->getSubject();
 
-        // do something with the mailer
+        // fare qualcosa col mailer
       }
     }
 
-La sezione seguente mostra come utilizzare in maniere proficua questa tecnica.
+La sezione seguente mostra come utilizzare in maniera proficua questa tecnica.
 
-### Utilizzo di ~Swift Mailer Plugins~
+### Utilizzo di ~Swift Mailer Plugin~
 
 Per utilizzare i plugin forniti da Swift Mailer, è sufficiente mettersi in ascolto dell'evento `mailer.configure`
 (vedere la sezione precedente):
@@ -637,12 +635,12 @@ Per utilizzare i plugin forniti da Swift Mailer, è sufficiente mettersi in asco
 >della documentazione ufficiale di Swift Mailer descrive tutto quello che c'è da sapere
 >sui plugin interni forniti dalla libreria.
 
-### Personalizzare il comportamento dello Spool
+### Personalizzare il comportamento dello spool
 
 L'implementazione degli spool fornita è molto semplice. Ogni spool
 recupera tutte le email dalla coda in ordine casuale e le invia.
 
-E' possibile configurare uno spool in modo tale da limitare il tempo speso nell'invio delle email (in secondi),
+È possibile configurare uno spool in modo tale da limitare il tempo speso nell'invio delle email (in secondi),
 o limitare il numero di messaggi da inviare:
 
     [php]
@@ -651,8 +649,8 @@ o limitare il numero di messaggi da inviare:
     $spool->setMessageLimit(10);
     $spool->setTimeLimit(10);
 
-Nella sezione corrente verrà illustrato come implementare un sistema proritario per la coda.
-Verrano fornite tutte le informazioni necessarie per l'implementazione di una logica persanalizzata.
+Nella sezione corrente verrà illustrato come implementare un sistema prioritario per la coda.
+Verranno fornite tutte le informazioni necessarie per l'implementazione di una logica personalizzata.
 
 Per prima cosa aggiungere una colonna `priority` allo schema:
 
@@ -670,7 +668,7 @@ Per prima cosa aggiungere una colonna `priority` allo schema:
         message:  { type: clob, notnull: true }
         priority: { type: integer }
 
-Durante l'invio di un'email è necessario impostare l'header di prorità (1 significa priorità massima)
+Durante l'invio di un'email è necessario impostare l'header di priorità (1 significa priorità massima)
 
     [php]
     $message = $this->getMailer()
@@ -679,7 +677,7 @@ Durante l'invio di un'email è necessario impostare l'header di prorità (1 sign
     ;
     $this->getMailer()->send($message);
 
-Dopodichè sovrascrivere il metodo predefinito `setMessage()`  in modo tale da cambiare la priorità
+Dopodiché sovrascrivere il metodo predefinito `setMessage()` in modo tale da cambiare la priorità
 dell'oggetto `MailMessage stesso: 
 
     [php]
@@ -750,7 +748,7 @@ In questo modo ogni volta che viene invocato il task `project:send-emails`
 ogni email verrà inviata in base alla priorità attribuita.
 
 >**SIDEBAR**
->Personalizzare lo Spool con diversi criteri
+>Personalizzare lo spool con diversi criteri
 >
 >L'esempio precedente utilizza un header standard del messaggio, la priorità. Ma se si volesse
 >utilizzare dei criteri diversi oppure se non si volesse alterare i messaggi inviati,
@@ -771,7 +769,7 @@ ogni email verrà inviata in base alla priorità attribuita.
 >       $this->getMailer()->send($message);
 >     }
 >
->Successivamente recuperare il valore dall'header nel momento che il messaggio
+>Successivamente recuperare il valore dall'header nel momento in cui il messaggio
 >viene aggiunto alla coda e rimuoverlo immediatamente:
 >
 >     [php]

From 7a8a1abc684776b06ef6e42f74535be2b1de6313 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Mon, 6 Sep 2010 13:23:31 +0200
Subject: [PATCH 09/10] [gentle][it] minor fixes

---
 gentle-introduction/it/10-Forms.markdown                    | 2 +-
 gentle-introduction/it/11-Emails.markdown                   | 2 +-
 .../it/A-Inside-the-Model-Layer-Propel.markdown             | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gentle-introduction/it/10-Forms.markdown b/gentle-introduction/it/10-Forms.markdown
index 9b225ba..27bb916 100644
--- a/gentle-introduction/it/10-Forms.markdown
+++ b/gentle-introduction/it/10-Forms.markdown
@@ -79,7 +79,7 @@ Con i parametri passati a setWidgets(), symfony ha informazioni sufficienti per
       </table>
     </form>
 
-Ogni widget viene convertito nella riga di una tabella contenente un tag <label> e un tag di input del form. Symfony deduce il nome della label dal nome del widget, convertendo l'iniziale in maiuscolo (il nome del widget `subject` dà la label `Subject`). Per quanto riguarda il tag di input, esso dipende dal tipo di widget. Symfony aggiunge un attributo `id` ad ogni widget, basandolo sul suo nome. Infine, la resa del form è sempre conforme alle specifiche XHTML.
+Ogni widget viene convertito nella riga di una tabella contenente un tag <label> e un tag di input del form. Symfony deduce il nome della label dal nome del widget, convertendo l'iniziale in maiuscolo (il nome del widget `subject` dà la label `Subject`). Per quanto riguarda il tag di input, esso dipende dal tipo di widget. Symfony aggiunge un attributo `id` a ogni widget, basandolo sul suo nome. Infine, la resa del form è sempre conforme alle specifiche XHTML.
 
 Personalizzare la visualizzazione del form
 ------------------------------------------
diff --git a/gentle-introduction/it/11-Emails.markdown b/gentle-introduction/it/11-Emails.markdown
index 4b46d71..fbf6b8d 100644
--- a/gentle-introduction/it/11-Emails.markdown
+++ b/gentle-introduction/it/11-Emails.markdown
@@ -764,7 +764,7 @@ ogni email verrà inviata in base alla priorità attribuita.
 >         ->compose('john@doe.com', 'foo@example.com', 'Subject', 'Body')
 >       ;
 >     
->       $message->getHeaders()->addTextHeader('X-Queue-Criteria', 'foò);
+>       $message->getHeaders()->addTextHeader('X-Queue-Criteria', 'pippo');
 >     
 >       $this->getMailer()->send($message);
 >     }
diff --git a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
index dab8be4..4c8a4c7 100644
--- a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
+++ b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
@@ -226,7 +226,7 @@ Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
 
 ### Recuperare i record correlati
 
-La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamente una chiave esterna verso la tabella `blog_article`. Ogni commento è collegato ad un articolo e un articolo può avere più commenti. Le classi generate possono contenere cinque metodi che traducono queste relazioni in codice ad oggetti, come segue:
+La colonna `blog_article_id` nella tabella `blog_comment` definisce implicitamente una chiave esterna verso la tabella `blog_article`. Ogni commento è collegato a un articolo e un articolo può avere più commenti. Le classi generate possono contenere cinque metodi che traducono queste relazioni in codice a oggetti, come segue:
 
   * `$comment->getArticle()`: Per ottenere il relativo oggetto `Article`
   * `$comment->getArticleId()`: Per ottenere l'ID del relativo oggetto `Article`
@@ -270,7 +270,7 @@ Il metodo `getArticle()` ritorna un oggetto di classe `Article`, con i benefici
 La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe `Comment`. Si può mostrare il primo con `$comments[0]` o iterare sulla collezione con `foreach ($comments as $comment)`.
 
 >**NOTE**
->Oggetti del modello sono definiti con un nome singolare per convenzione, e ora si capisce perché. La chiave esterna definita nella tabelle `blog_comment` causa la creazione del metood `getComments()`, chiamato aggiungendo una `s` al nome dell'oggetto `Comment`. Se tu dessi un nome plurale al modello, la generazione porterebbe ad un metodo chiamato `getCommentss()`, che non avrebbe senso.
+>Oggetti del modello sono definiti con un nome singolare per convenzione, e ora si capisce perché. La chiave esterna definita nella tabelle `blog_comment` causa la creazione del metood `getComments()`, chiamato aggiungendo una `s` al nome dell'oggetto `Comment`. Se tu dessi un nome plurale al modello, la generazione porterebbe a un metodo chiamato `getCommentss()`, che non avrebbe senso.
 
 ### Salvare ed eliminare dati
 
@@ -354,7 +354,7 @@ Listato 8-13 - Recuperare record usando Criteria e `doSelect()`--Criteria con co
 Le costanti di classe passate come parametri dei metodi `add()` si riferiscono ai nomi delle propietà. Sono chiamate con la versione maiuscola dei nomi delle colonne. Per esempio, per la colonna `content` della tabella `blog_article`, usa la costante `ArticlePeer::CONTENT`.
 
 >**NOTE**
->Perché usare `CommentPeer::AUTHOR` al posto di `blog_comment.AUTHOR`, che è quello che sarà utilizzato nel codice SQL in ogni caso? Supponi di dover cambiare il nome della colonna da `author` a `contributor` nel database. Se tu avessi usato `blog_comment.AUTHOR`, dovresti cambiarlo ad ogni chiamata del metodo. Invece, usando `CommentPeer::AUTHOR`, devi soltanto cambiare il nome della colonna nel file `schema.yml`, impostare il valore `phpName` ad `AUTHOR` e ricostruire il modello.
+>Perché usare `CommentPeer::AUTHOR` al posto di `blog_comment.AUTHOR`, che è quello che sarà utilizzato nel codice SQL in ogni caso? Supponi di dover cambiare il nome della colonna da `author` a `contributor` nel database. Se tu avessi usato `blog_comment.AUTHOR`, dovresti cambiarlo a ogni chiamata del metodo. Invece, usando `CommentPeer::AUTHOR`, devi soltanto cambiare il nome della colonna nel file `schema.yml`, impostare il valore `phpName` ad `AUTHOR` e ricostruire il modello.
 
 La Tabella 8-1 confronta la sintassi SQL con quella della classe `Criteria`.
 

From e716846b3400f8df5c714cc115d8a99c3956bc49 Mon Sep 17 00:00:00 2001
From: Massimiliano Arione <garakkio@gmail.com>
Date: Fri, 10 Sep 2010 13:43:53 +0200
Subject: [PATCH 10/10] [it] finished gentle appendix A and uniformted other
 chapters

---
 .../it/02-Exploring-Symfony-s-Code.markdown   | 231 ++++++------
 .../04-The-Basics-of-Page-Creation.markdown   |   8 +-
 .../it/05-Configuring-Symfony.markdown        |  48 +--
 .../06-Inside-the-Controller-Layer.markdown   |  16 +-
 .../it/07-Inside-the-View-Layer.markdown      |   8 +-
 ...8-Inside-the-Model-Layer-Doctrine.markdown | 203 +++++-----
 gentle-introduction/it/10-Forms.markdown      |   8 +-
 .../it/13-I18n-and-L10n.markdown              |   6 +-
 .../16-Application-Management-Tools.markdown  |  10 +-
 .../it/17-Extending-Symfony.markdown          |   2 +-
 ...ing-Symfony-s-Configuration-Files.markdown |  32 +-
 .../A-Inside-the-Model-Layer-Propel.markdown  | 347 +++++++++---------
 reference/it/10-Routing.markdown              |   2 +-
 tutorial/it/upgrade.markdown                  |   6 +-
 tutorial/it/whats-new.markdown                |  44 +--
 15 files changed, 484 insertions(+), 487 deletions(-)

diff --git a/gentle-introduction/it/02-Exploring-Symfony-s-Code.markdown b/gentle-introduction/it/02-Exploring-Symfony-s-Code.markdown
index bd922e6..2bcc7f8 100644
--- a/gentle-introduction/it/02-Exploring-Symfony-s-Code.markdown
+++ b/gentle-introduction/it/02-Exploring-Symfony-s-Code.markdown
@@ -1,15 +1,15 @@
 Capitolo 2 - Esplorazione del codice di symfony
 ===============================================
 
-In un primo momento l'esplorazione del codice alla base di un applicativo scritto utillizzando symfony può sembrare scoraggiante. 
-Il codice è costituito da molteplici directory e script, i vari file sono un mix di classi PHP, HTML e a volte una combinazione di entrambi. 
-Capiterà anche di trovare riferimenti a classi che non sono presenti all'interno della directory 
-dell'applicativo oppure constatare che si può arrivare ad una profondità delle directory di ben sei livelli. 
+In un primo momento l'esplorazione del codice alla base di un applicativo scritto utilizzando symfony può sembrare scoraggiante. 
+Il codice è costituito da molteplici cartelle e script, i vari file sono un mix di classi PHP, HTML e a volte una combinazione di entrambi. 
+Capiterà anche di trovare riferimenti a classi che non sono presenti all'interno della  cartella 
+dell'applicativo oppure constatare che si può arrivare a una profondità delle cartelle di ben sei livelli. 
 Ma una volta compresa la ragione di questa apparente complessità, ci si sentirà talmente a proprio agio che non si vorrebbe assolutamente cambiare la struttura 
 dell'applicativo symfony con nessun'altra.
 
 Pattern MVC
----------------
+-----------
 
 Symfony è basato sul classico web design pattern conosciuto come architettura MVC, che consiste di tre livelli:
 
@@ -35,15 +35,15 @@ Figure 2-1 - Il pattern MVC
 ### I livelli dell'MVC
 
 Per comprendere i vantaggi del pattern MVC, verrà illustrato di seguito come convertire un'applicazione base PHP 
-nel sudetto pattern architetturale. 
-Un perfetto esempio e' dato da una lista di post di un web blog.
+nel suddetto pattern architetturale. 
+Un perfetto esempio è dato da una lista di post di un web blog.
 
 #### Programmazione "piatta"
 
 Se si volesse mostrare una lista di record estratti da un database utilizzando un unico script PHP 
 si utilizzerebbe del codice simile a quello mostrato nel Listato 2-1
 
-Listing 2-1 - Un'unico Script
+Listato 2-1 - Un'unico Script
 
 
     [php]
@@ -91,9 +91,9 @@ I maggiori problemi che si possono incontrare utilizzando questo codice e questo
 
   * Non è presente un controllo degli errori (cosa succederebbe se la connessione al db fallisse?)
   * Codice HTML e codice PHP mischiati e intrecciati tra di loro.
-  * Il codice e' legato al database MYSQL.
+  * Il codice è legato al database MYSQL.
 
-#### Isolare la Presentazione
+#### Isolare la presentazione
 
 Le chiamate `echo` e `printf` presenti nel Listato 2-1 rendono il codice difficile da leggere. 
 Diventerebbe un'operazione onerosa e complessa modificare il codice HTML per migliorarne la presentazione. 
@@ -149,8 +149,8 @@ Listato 2-3 - La Vista, in `view.php`
     </html>
 
 Una buona regola per determinare se la vista è sufficientemente chiara e pulita dal punto di vista del codice che la compone
- è controllare che essa contenga soltanto un minimo quantitativo di codice PHP, in modo tale che sia facilmente comprensibile ad un designer HTML 
- che non abbia conoscenza del linguaggio PHP.
+è controllare che essa contenga soltanto un minimo quantitativo di codice PHP, in modo tale che sia facilmente comprensibile a un designer HTML 
+che non abbia conoscenza del linguaggio PHP.
 Le espressioni PHP più comuni presenti nelle vista sono `echo`, `if/endif`, `foreach/endforeach`. 
 Inoltre non dovrebbe esserci codice PHP che stampi codice HTML.
 
@@ -197,7 +197,7 @@ Listato 2-4 - Il modello, in `model.php`
       return $posts;
     }
 
-Il controllore rivisto e riscritto e' mostrato nel Listato 2-5
+Il controllore rivisto e riscritto è mostrato nel Listato 2-5
 
 Listato 2-5,- Il controllore, rivisto, in `index.php`
 
@@ -213,10 +213,10 @@ Listato 2-5,- Il controllore, rivisto, in `index.php`
     // Richeista della vista
     require('view.php');
 
-In questo modo diventa piu semplice leggere il codice del controllore.
+In questo modo diventa più semplice leggere il codice del controllore.
 Il suo unico scopo è quello di ottenere i dati dal modello e passarli alla vista.
 In un'applicazione più complessa, il controllore controlla anche con la richiesta, la sessione utente, l'autenticazione, e così via.
-L'utilizzo di nomi espliciti per le funzioni del modello rende adirittura non necessario l'utilizzo dei commenti 
+L'utilizzo di nomi espliciti per le funzioni del modello rende addirittura non necessario l'utilizzo dei commenti 
 nel controllore.
 
 Lo script del modello è dedito all'accesso dei dati e può essere organizzato di conseguenza.
@@ -232,7 +232,7 @@ La logica che gestisce i dati appartiene al modello, la gestione del codice di p
 L'utilizzo di altri pattern di design possono rendere ancora più semplice l'esperienza di sviluppo e scrittura del codice dell'applicativo.
 I livelli modello, vista e controllore possono al loro volta essere suddivisi.
 
-### Astrazione del Database
+### Astrazione del database
 
 Il livello del modello può essere suddiviso a sua volta in un livello di accesso ai dati e un livello di astrazione del database.
 In questo modo, le funzioni di accesso ai dati non utilizzeranno query dipendenti dal tipo di database scelto, 
@@ -300,20 +300,20 @@ che richiedano accesso al database.
 
 >**NOTE**
 >Gli esempi mostrati nei Listati 2-6 e 2-7 non risultano ancora del tutto soddisfacenti in quanto ci sarebbe ancora del codice da scrivere
->per poter ottenere una completa e reale astrazione del database (astrazione del codice SQL attravero un costruttore di query,
-> spostamento di tutte le funzioni in una classe, e cos via). Ma lo scopo di questa guida non e' mostrare come si debba scrivere
-> tutto questo codice, e verrà mostrato nel Capitolo 8 come symfony fornisce già elegantemente questa astrazione.
+>per poter ottenere una completa e reale astrazione del database (astrazione del codice SQL attraverso un costruttore di query,
+> spostamento di tutte le funzioni in una classe, e così via). Ma lo scopo di questa guida non è mostrare come si debba scrivere
+> tutto questo codice, e verrà mostrato nel capitolo 8 come symfony fornisce già elegantemente questa astrazione.
 
 
 ### Elementi della Vista
 
 Il livello della vista può beneficiare a sua volta di una separazione interna del codice.
-Una pagina web contiene spesso degli elementi presenti e consistentia in tutto l'applicativo: gli header della pagina
-il layout grafico, il footer, e il menu' di navigazione. In generale soltanto le parti interne della pagina cambiano.
-Per questo motivo la vista e' separata in altri due livelli: layout e template.
-Il layout e' solitamente globale nell'applicativo o comunque accomuna un gruppo di pagine.
+Una pagina web contiene spesso degli elementi coerenti in tutto l'applicativo: gli header della pagina
+il layout grafico, il footer e il menù di navigazione. In generale soltanto le parti interne della pagina cambiano.
+Per questo motivo la vista è separata in altri due livelli: layout e template.
+Il layout è solitamente globale nell'applicativo o comunque accomuna un gruppo di pagine.
 Il template si occupa di mostrare i valori delle variabili messe a disposizione dal controllore.
-E' necessaria della logica per poter far in modo che queste componenti lavorino insieme, e questa logica di presentazione e'
+È necessaria della logica per poter far in modo che queste componenti lavorino insieme, e questa logica di presentazione è
 gestita appunto dalla vista.
 In base a questi principi, la parta di vista del Listato 2-3 può essere separate in tre parti,
 come mostrato dai Listati 2-8, 2-9 e 2-10.
@@ -354,37 +354,37 @@ Listato 2-10 - La parte di layout della vista
       </body>
     </html>
 
-#### Azioni e Front Controller
+#### Azioni e front controller
 
 Il controllore mostrato nell'esempio precedente non effettua molte operazioni, ma in una applicazione web reale, esso deve svolgere molti compiti. 
 Un compito importante e comune a tutti i controllori dell'applicativo.
-Un compito comune include la gestione della request, sicurezza, caricamento delle configurazuone e faccende simili.
+Un compito comune include la gestione della richiesta, sicurezza, caricamento delle configurazione e faccende simili.
 Questo è il motivo per cui spesso il controllore è suddiviso in un front controller, che è unico in tutto l'applicativo, e azioni
 che contengono solamente il codice del controllore specifico di una pagina.
 
 Uno dei grandi vantaggi nell'avere un front controller è che viene offerto un unico punto di accesso per tutto l'applicativo.
-Qualora si decidesse di rendere inacessibile l'applicativo, basterà semplicemente modificare lo script del front controller.
+Qualora si decidesse di rendere inaccessibile l'applicativo, basterà semplicemente modificare lo script del front controller.
 In un'applicativo sprovvisto di front controller, si dovrebbe intervenire su ogni singolo controllore per poter ottenere lo stesso effetto.
 
-#### Orientamento agli Oggetti
+#### Orientamento agli oggetti
 
 Tutti gli esempi mostrati in precedenza sono stati scritti con un paradigma di programmazione procedurale.
 Le possibilità offerte dalla OOP dei moderni linguaggi di programmazione rende la programmazione stessa più semplice, dato che gli oggetti incapsulano logica,
 ereditano uno dall'altro e forniscono un chiaro e pulito utilizzo dei nomi.
 
-Implementare un'architettura MVC con un linguaggio che non sia object-oriented produrrebbe problematiche nella gestione dei namespace, duplicazione del codice
+Implementare un'architettura MVC con un linguaggio che non sia orientato agli oggetti produrrebbe problematiche nella gestione dei namespace, duplicazione del codice
 e supratutto un codice difficile da leggere.
 
 Lo sviluppo orientato agli oggetti permette agli sviluppatori di utilizzare strumenti e componenti come l'oggetto vista, l'oggetto controllore
 le classi di modello e trasformare tutte le funzioni degli esempi precedenti in metodi.
-E' una necessita' per un'architettura MVC.
+È una necessità per un'architettura MVC.
 
 
 
 >**TIP**
 > Se si volesse approfondire meglio i vari design pattern per un applicativo web in un contesto object-oriented
 > si consiglia la lettura di Patterns of Enterprise Application Architecture by Martin Fowler (Addison-Wesley, ISBN: 0-32112-742-0).
->Il codice d'esempio presente nel libro di Fowler e' scritto in Java o C#, ma e' piuttosto comprensibile anche ad uno sviluppatore PHP.
+>Il codice d'esempio presente nel libro di Fowler è scritto in Java o C#, ma è piuttosto comprensibile anche a uno sviluppatore PHP.
 
 ### Implementazione del pattern MVC di symfony
 
@@ -412,30 +412,30 @@ Sette script, diversi file da aprire e modificare ogni volta che si crea una pag
 Ciò nonostante symfony rende le cose semplici. Symfony implementa il meglio dell'architettura MVC
 in modo da rendere veloce e indolore lo sviluppo di una applicazione.
 
-Per prima cosa, il Front Controlle e il layout sono gli stessi per tutte le azioni dell'applicativo.
+Per prima cosa, il Front Controller e il layout sono gli stessi per tutte le azioni dell'applicativo.
 È possibile avere controllori e layout multipli, ma è necessario solo uno di essi.
-Il Front controller e' un componente puramente in logica MVC e non ci sarà mai l'esigenza di scriverne uno perche'
+Il Front controller è un componente puramente in logica MVC e non ci sarà mai l'esigenza di scriverne uno perché
 symfony si preoccuperà di generarlo.
 
 L'altra buona notizia è che le classi del modello sono anch'esse generate automaticamente,
-basandosi sulla struttura dei dati. Questo compito di autogenerazione delle classi del modello è affidato alla libreria ORM, che fornisce lo scheletro e la generazione del codice.
+basandosi sulla struttura dei dati. Questo compito di auto-generazione delle classi del modello è affidato alla libreria ORM, che fornisce lo scheletro e la generazione del codice.
 Se la libreria ORM trovasse una chiave esterna o un campo data, genererà degli speciali metodi che renderanno estremamente semplice la manipolazione dei dati e le relazioni tra essi.
-La parte di astrazione del database è totalmente invisibile perché viene gestita nativamente da PHP Data Objects.
-Qualora si decidesse di cambiare il motore del database, non si dovra' toccare minimamente una singola riga di codice applicativo.
+La parte di astrazione del database è totalmente invisibile perché viene gestita nativamente da oggetti PHP.
+Qualora si decidesse di cambiare il motore del database, non si dovrà toccare minimamente una singola riga di codice applicativo.
 Occorre solamente cambiare un parametro di configurazione.
 
 
 Inoltre la logica della vista può essere descritta attraverso un semplice file di configurazione, senza che ci sia la necessità
-di scrivere dell codice applicativo.
+di scrivere del codice applicativo.
 
-Figura 2-2 - Symfony workflow
+Figura 2-2 - Flusso di lavoro di symfony
 
-![Symfony workflow](http://www.symfony-project.org/images/book/1_4/F0202.png "Symfony workflow")
+![Flusso di lavoro di symfony](http://www.symfony-project.org/images/book/1_4/F0202.png "Flusso di lavoro di symfony")
 
 Questo significa che per quanto riguarda la lista dei post descritta in precedenza saranno necessari solamente tre file
 come mostrato nei Listati 2-11, 2-12, e 2-13.
 
-Listato 2-11 - `list` Action, in `myproject/apps/myapp/modules/weblog/actions/actions.class.php`
+Listato 2-11 - Azione `list`, in `myproject/apps/myapp/modules/weblog/actions/actions.class.php`
 
     [php]
     <?php
@@ -448,7 +448,7 @@ Listato 2-11 - `list` Action, in `myproject/apps/myapp/modules/weblog/actions/ac
       }
     }
 
-Listato 2-12 - `list` Template, in `myproject/apps/myapp/modules/weblog/templates/listSuccess.php`
+Listato 2-12 - Template `list`, in `myproject/apps/myapp/modules/weblog/templates/listSuccess.php`
 
     [php]
     <?php slot('title', 'List of Posts') ?>
@@ -464,7 +464,7 @@ Listato 2-12 - `list` Template, in `myproject/apps/myapp/modules/weblog/template
     <?php endforeach; ?>
     </table>
 
-Si dovrà definira un layout, come mostrato nel Listato 2-13, ma esso sarà riutilizzato diverse volte.
+Si dovrà definire un layout, come mostrato nel Listato 2-13, ma esso sarà riutilizzato diverse volte.
 
 Listato 2-13 - Layout, in `myproject/apps/myapp/templates/layout.php`
 
@@ -491,12 +491,12 @@ di gestione degli URL, ambienti  multipli e tanti altri strumenti di sviluppo.
 
 L'implementazione MVC in symfony utilizza diverse classi che verranno spesso citate all'interno di questa guida:
 
-  * `sfController` è la classe controllore. Decodifica la request e la inoltra alla action.
-  * `sfRequest` immagazzina tutti gli elementi della request (parametri, cookies, headers e così via).
-  * `sfResponse` contiente gli header e il contenuto della response. Questo è l'oggetto che sarà eventualmente convertito in una response HTML e che a sua volta sarà inviata all'utente.
+  * `sfController` è la classe controllore. Decodifica la richiesta e la inoltra all'azione.
+  * `sfRequest` immagazzina tutti gli elementi della richiesta (parametri, cookies, headers e così via).
+  * `sfResponse` contiente gli header e il contenuto della risposta. Questo è l'oggetto che sarà eventualmente convertito in una risposta HTML e che a sua volta sarà inviata all'utente.
   * Il contesto (ottenuto invocando `sfContext::getInstance()`) mantiene una referenza a tutti gli oggetti principali e alla configurazione corrente; è accessibile in ogni punto dell'applicativo.
 
-Nel capitolo 6 questi oggetti verrano approfonditi maggiormente.
+Nel capitolo 6 questi oggetti verranno approfonditi maggiormente.
 
 Come si può notare, tutte le classi fornite da symfony utilizzano il prefisso 'sf', così come le variabili del nocciolo nei template. 
 Questo serve a scongiurare problematiche relative all'utilizzo di nomi per variabili e classi utilizzate dallo sviluppatore e rendendo semplice il loro riconoscimento.
@@ -506,11 +506,11 @@ Questo serve a scongiurare problematiche relative all'utilizzo di nomi per varia
 >Ci sono due eccezioni: le classi del nocciolo iniziano con `sf`, in minuscolo, e le variabili nei template utilizzano
 >il trattino basso come separatore.
 
-Organizzazione del Codice
------------------
+Organizzazione del codice
+-------------------------
 
-Dopo aver illustrato i diversi componenti di un'applicazione symofony, mostraimo come essi sono sono organizzati.
-Symfony organizza il codice in una struttura di progetto e colloca i file in una struttura standar ad albero.
+Dopo aver illustrato i diversi componenti di un'applicazione symofony, mostriamo come essi sono sono organizzati.
+Symfony organizza il codice in una struttura di progetto e colloca i file in una struttura standard ad albero.
 
 ### Struttura di Progetto, Applicazioni, Moduli e Azioni
 
@@ -518,7 +518,7 @@ In symfony, un progetto è un insieme di servizi e operazioni disponibili sotto
 condividendo lo stesso modello.
 
 All'interno di un progetto, le operazioni sono raggruppate in modo logico all'interno delle applicazioni. 
-Un'applicazione può normalemnte girare indipendentemente dalle altre applicazioni dello stesso progetto.
+Un'applicazione può normalmente girare indipendentemente dalle altre applicazioni dello stesso progetto.
 Nella maggior parte dei casi, un progetto conterrà due applicazioni: una per il front-office e un per il back-office.
 condividendo lo stesso database. Ma è possibile avere anche un progetto contenente dei mini-siti,
 un'applicazione per ogni sito. Da notare che i link tra le applicazioni devono essere in forma assoluta.
@@ -530,42 +530,42 @@ Ad esempio si potrebbe avere dei moduli `home`, `articoli`, `help`, `carrelloDel
 I moduli contengono le azioni, le quali rappresentano le varie azioni che possono essere eseguite all'interno di un modulo.
 Per esempio, un modulo nominato `carrelloDellaSpesa` può contenere le azioni `aggiungi`, `mostra` e aggiorna.
 Aver a che fare con le azioni è quasi come interagire con le pagine di una classica applicazione web, sebbene due azioni 
-possano risultare nella stessa pagina (ad esempio, aggiungendo un commento ad un post in un weblog comporterà la rivisualizzazione del post con il nuovo commento).
+possano risultare nella stessa pagina (ad esempio, aggiungendo un commento a un post in un blog comporterà la ri-visualizzazione del post con il nuovo commento).
 
 >**TIP**
 >Se ci fossero troppi livelli di moduli e azioni per un progetto iniziale, è possibile raggruppare tutte le azioni in un singolo modulo,
->in modo tale che la stuttura si mantenga semplice. Nel caso in cui successivamente l'applicazione diventi più complessa,
+>in modo tale che la struttura si mantenga semplice. Nel caso in cui successivamente l'applicazione diventi più complessa,
 >sarà necessario disporre le azioni in moduli separati.
->Come descritto nel Capitolo 1, l'operazione di riscrivere il codice per migliorare la struttura e la leggibilità dello stesso (ma preservando il suo comportamento)
->viene comunemente chiamato `refactoring`, e questo viene fatto frequentemente applicando i principi RAD.
+>Come descritto nel capitolo 1, l'operazione di riscrivere il codice per migliorare la struttura e la leggibilità dello stesso (ma preservando il suo comportamento)
+>viene comunemente chiamato 'rifattorizzazione' e questo viene fatto frequentemente applicando i principi RAD.
 
-La Figura 2-3 mostra un esempio di codice per un progetto di un weblog, in una struttura project/application/module/action.
+La Figura 2-3 mostra un esempio di codice per un progetto di un blog, in una struttura `project/application/module/action`.
 
 Figura 2-3 - Esempio di organizzazione del codice
 
-![Example of code organization](http://www.symfony-project.org/images/book/1_4/F0203.png "Example of code organization")
+![Esempio di organizzazione del codice](http://www.symfony-project.org/images/book/1_4/F0203.png "Esempio di organizzazione del codice")
 
-### Strutture ad Albero dei File
+### Strutture ad albero dei file
 
-Tutti i progetti web condividono lo stesso tipo di contenuti, as esempio:
+Tutti i progetti web condividono lo stesso tipo di contenuti, ad esempio:
 
   * Un database, come MYSQL o PostgreSQL
-  * File statici (HTML, immagini, file Javascript, fogli di stile e così via)
+  * File statici (HTML, immagini, file JavaScript, fogli di stile e così via)
   * File caricati dagli utenti del sito e gli amministratori
   * Classi e librerie PHP
   * Librerie esterne (script di terze parti)
-  * File Batch (scipt che vengono lanciati da linea di comando o via cron)
+  * File Batch (script che vengono lanciati da linea di comando o via cron)
   * File di Log (informazioni scritte dall'applicativo e/o dal server)
   * File di configurazione
   
 Symfony fornisce una struttura di file standard per organizzare tutti questi contenuti in modo logico e
 consistente con le scelte architetturali (MVC pattern e raggruppamento progetto/applicazione/modulo).
 Questa è la struttura che viene creata quando si inizializza un progetto, applicazione o modulo.
-Ovviamente è possibile personalizzare completamente la struttura dei file e delle directory qualora fosse necessario.
+Ovviamente è possibile personalizzare completamente la struttura dei file e delle cartelle, qualora fosse necessario.
 
 #### Struttura principale dell'albero
 
-Queste sono le directory alla base di un progetto symfony:
+Queste sono le cartelle alla base di un progetto symfony:
 
     apps/
       frontend/
@@ -589,25 +589,24 @@ Queste sono le directory alla base di un progetto symfony:
       js/
       uploads/
 
-Tabella 2-1 descrive il contenuto delle directory mostrate
+Tabella 2-1 descrive il contenuto delle cartelle mostrate
 
-Tabella 2-1 - Directory di base
+Tabella 2-1 - Cartelle di base
 
-Directory  |  Description
----------- | ------------
-`apps/`    | Contiene una directory per ogni applicazione del progetto (tipicamente, `frontend` and `backend` pre il front e back office).
-`cache/`   | Contiene la versione cache della configurazione, e (se attivata) la versione cache delle azioni e dei template del progetto. Il meccanismo di caching (descitto nel capitolo 12) utilizza questi file per velocizzare i tempi di risposta dell'applicativo. Ciascuna applicazione avrà una subdirectory, contenente file PHP preprocessati e file HTML.
-`config/`  | Holds the general configuration of the project.
+Cartella   | Descrizione
+---------- | -----------
+`apps/`    | Contiene una  cartella per ogni applicazione del progetto (tipicamente, `frontend` e `backend`).
+`cache/`   | Contiene la versione cache della configurazione, e (se attivata) la versione cache delle azioni e dei template del progetto. Il meccanismo di cache (descritto nel capitolo 12) utilizza questi file per velocizzare i tempi di risposta dell'applicativo. Ciascuna applicazione avrà una sotto-cartella, contenente file PHP pre-processati e file HTML.
 `config/`  | Contiene la configurazione generale del progetto.
 `data/`    | Contiene i file dati del progetto come lo schema del database, un file SQL per la creazione delle tabelle o anche un file SQLite.
 `doc/`     | Contiene la documentazione del progetto
-`lib/`     | Contiene classi esterne o librerie. In essa può essere aggiunto del codice che deve essere condiviso tra le applicazioni. La subdirectory `model/` contiene gli oggetti del modello del progetto (descritto nel Capitolo 8).
-`log/`     | Contiene i file di log generati direttamente da symfony. Possono anche essere presenti i file di log del webserver, del database o file di log provenienti da qualsiasi punto del progetto. Symfony crea un file di log per ogno applicazioni e ambiente (i file di log verranno discussi nel Capitolo 16).
-`plugins/` | Contiene i vari plugin installati nell'applicativo (i plugin verranno discussi nel Capitolo 17).
-`test/`    | Contiene test unitari e funzionali scritti in PHP e compatibili con il framework di test di symfony (discusso nel Capitolo 15). Durante il setup de progetto, symfony crea automaticamente dei file con dei test basilari.
-`web/`     | È la directory root per il webserver. Essa contieni gli unici file accessibili dall'esterno.
+`lib/`     | Contiene classi esterne o librerie. In essa può essere aggiunto del codice che deve essere condiviso tra le applicazioni. La sotto-cartella `model/` contiene gli oggetti del modello del progetto (descritto nel capitolo 8).
+`log/`     | Contiene i file di log generati direttamente da symfony. Possono anche essere presenti i file di log del webserver, del database o file di log provenienti da qualsiasi punto del progetto. Symfony crea un file di log per ogni applicazione e ambiente (i file di log verranno discussi nel capitolo 16).
+`plugins/` | Contiene i vari plugin installati nell'applicativo (i plugin verranno discussi nel capitolo 17).
+`test/`    | Contiene test unitari e funzionali scritti in PHP e compatibili con il framework di test di symfony (discusso nel capitolo 15). Durante il setup del progetto, symfony crea automaticamente dei file con dei test basilari.
+`web/`     | È la cartella radice del server web. Essa contiene gli unici file accessibili dall'esterno.
 
-#### Struttura ad Albero di un'Applicazione
+#### Struttura ad albero di un'applicazione
 
 La struttura ad albero di un'applicazione è la stessa:
 
@@ -620,20 +619,20 @@ La struttura ad albero di un'applicazione è la stessa:
         templates/
           layout.php
 
-Tabella 2-2 descrive le subdirectory dell'applicazione
+Tabella 2-2 descrive le sotto-cartelle dell'applicazione
 
-Tabella 2-2 - Subdirectory dell'applicazione
+Tabella 2-2 - Sotto-cartelle dell'applicazione
 
-Directory    | Description
+Cartella     | Descrizione
 ------------ | -----------
-`config/`    | Contiene un insieme di file di configurazione YAML. In questa subdirectory sono contenuti i principali di configurazione, escludendo i parametri iniziali definiti nel framework stesso. Se fosse necessario i valori dei parametri iniziali posso essere comunque sovrascritti. Questo argomento verra' trattato nello specifico nel Capitolo 5.
-`i18n/`      | Contiene i file utilizzati per l'intenazionalizzazione dell'applicativo (il Capitolo 13 approfondisce l'argomento). E' possibile non tenere conto di questa directory qualora si utilizzasse un database per l'internazionalizzazione.
+`config/`    | Contiene un insieme di file di configurazione YAML. In questa sotto-cartelle sono contenuti i principali di configurazione, escludendo i parametri iniziali definiti nel framework stesso. Se fosse necessario i valori dei parametri iniziali posso essere comunque sovrascritti. Questo argomento verrà trattato nello specifico nel capitolo 5.
+`i18n/`      | Contiene i file utilizzati per l'internazionalizzazione dell'applicativo (il capitolo 13 approfondisce l'argomento). È possibile non tenere conto di questa  cartella qualora si utilizzasse un database per l'internazionalizzazione.
 `lib/`       | Contiene classi e librerie specifiche all'applicazione.
 `modules/`   | Contiene tutti i  moduli dell'applicazione
 `templates/` | Contiene i template globali dell'applicazione, condivisi da tutti i moduli. Contiene il file `layout.php` come predefinito, che rappresenta il layout principale nel quale i template dei moduli vengono inseriti.
 
 >**NOTE**
->Le directory `i18n/`, `lib/` e  `modules/` sono vuote quando viene creata una nuova applicazione.
+>Le cartelle `i18n/`, `lib/` e  `modules/` sono vuote quando viene creata una nuova applicazione.
 
 Le classi di un'applicazione non possono accedere a metodi o attributi di altre applicazioni dello stesso progetto. 
 Da notare che i link tra le diverse applicazioni devono essere in forma assoluta e quindi è da tener ben presente qualora si decidesse di suddividere un progetto in diverse applicazioni.
@@ -642,7 +641,7 @@ Da notare che i link tra le diverse applicazioni devono essere in forma assoluta
 #### Struttura ad albero di un modulo
 
 Ogni applicazione contiene uno o più moduli.
-Ogni modulo ha le sue subdirectory nella direcotory `modules`, e il nome di tale directory viene scelta durante il setup.
+Ogni modulo ha le sue sotto-cartelle nella cartella `modules` e il nome di tale  cartella viene scelta durante la configurazione.
 
 Tipica struttura ad albero di un modulo:
 
@@ -657,25 +656,25 @@ Tipica struttura ad albero di un modulo:
               templates/
                 indexSuccess.php
 
-Tabella 2-3 descrive le subdirectory di un modulo.
+Tabella 2-3 descrive le sotto-cartelle di un modulo.
 
-Tabella 2-3 - Subdirectory di un modulo
+Tabella 2-3 - Sotto-cartelle di un modulo
 
-Directory    | Description
------------- | ------------
-`actions/`   | Contiene generalmente un singolo file chiamato `actions.class.php`, nel quale sono scritte tutte le azione del modulo stesso. E' possibile scrivere azioni diverse di un modulo in file separati.
+Cartella     | Descrizione
+------------ | -----------
+`actions/`   | Contiene generalmente un singolo file chiamato `actions.class.php`, nel quale sono scritte tutte le azioni del modulo stesso. È possibile scrivere azioni diverse di un modulo in file separati.
 `config/`    | Contiene file di configurazione personalizzati con parametri locali per il modulo.
 `lib/`       | Contiene classi e librerie specifiche del modulo.
 `templates/` | Contiene i template corrispondenti all'azione del modulo. Un template predefinito, chiamato `indexSuccess.php`, viene creato durante il setup del modulo.
 
 >**NOTE**
->Le directory `config/` e `lib/` non vengono create automaticamente per un nuovo modulo, devono essere create manualmente qualora fossero necessarie.
+>Le cartelle `config/` e `lib/` non vengono create automaticamente per un nuovo modulo, devono essere create manualmente qualora fossero necessarie.
 
-#### Struttura ad albero della directory Web
+#### Struttura ad albero della cartella Web
 
-Esistono pochi vincoli per la directory `web`, essa è la directory contenente file accessibili pubblicamente dall'esterno.
-Seguendo poche regole base sarà possibile ottenere dei comportamenti predefiniti, messi a diposizione dal framework stesso, e utili scorciatoie da utilizzare all'interno dei template. 
-Esempio della struttura della directory `web`:
+Esistono pochi vincoli per la cartella `web`, essa è la cartella contenente file accessibili pubblicamente dall'esterno.
+Seguendo poche regole base sarà possibile ottenere dei comportamenti predefiniti, messi a disposizione dal framework stesso, e utili scorciatoie da utilizzare all'interno dei template. 
+Esempio della struttura della  cartella `web`:
 
     web/
       css/
@@ -683,30 +682,30 @@ Esempio della struttura della directory `web`:
       js/
       uploads/
 
-È convenzione che i file statici vengano collocati nell directory mostrate nella Tabella 2-4
+È convenzione che i file statici vengano collocati nella  cartella mostrate nella Tabella 2-4
 
-Tabella 2-4 Sottodirectory tipiche della directory Web
+Tabella 2-4 Sotto cartella tipiche della  cartella Web
 
-Directory  | Description
+Cartella   | Descrizione
 ---------- | -----------
 `css/`     | Contiene fogli di stile con estensione `.css`.
 `images/`  | Contiene immagini con estensione `.jpg`, `.png`, o `.gif`.
-`js/`      | Contiene file Javascript con estensione `.js`.
-`uploads/` | Contiene file caricati dagli utenti. Sebbene la directory contenga solitamente immagini, è separata dalla directory delle immagini in modo che la sincronizzazione dei server di sviluppo e server di produzione non interferisca con le immagini caricate.
+`js/`      | Contiene file JavaScript con estensione `.js`.
+`uploads/` | Contiene file caricati dagli utenti. Sebbene la  cartella contenga solitamente immagini, è separata dalla  cartella delle immagini in modo che la sincronizzazione dei server di sviluppo e server di produzione non interferisca con le immagini caricate.
 
 >**NOTE**
 >Sebbene sia altamente consigliato che venga mantenuta la struttura ad albero predefinita, è possibile modificarla 
->per esigenze specifiche, ad esempio per permettere ad un progetto di girare su un server con strutture particolari. 
->Per maggiori informazioni su quest'ultimo argomento è necessario riferirsi al Capitolo 19 nel quale verrà mostrato come modificare la struttura ad albero dei file.
+>per esigenze specifiche, ad esempio per permettere a un progetto di girare su un server con strutture particolari. 
+>Per maggiori informazioni su quest'ultimo argomento è necessario riferirsi al capitolo 19 nel quale verrà mostrato come modificare la struttura ad albero dei file.
 
 
-Strumenti Comuni
-------------------
+Strumenti comuni
+----------------
 
 Durante la lettura di questa guida e nello sviluppo di progetti con symfony si incontreranno alcune tecniche utilizzate ripetutamente.
 Tra queste ci sono: contenitori dei parametri, costanti e caricamento automatico delle classi.
 
-### Contentori di Parametri
+### Contenitori di parametri
 
 Molte delle classi che compongono il framework symfony sono dei contenitori di parametri. 
 È un modo conveniente di incapsulare gli attributi con dei metodi getter e setter chiari e puliti.
@@ -732,13 +731,13 @@ Listato 2-15 - Utilizzo del metodo proxy del contenitore dei parametri dell'ogge
      => 'bar'
 
 Il metodo getter del contenitore di parametri accetta un valore predefinito come secondo argomento.
-Tutto ciò fornisce un utile meccanismo di fallback che risulta molto più consico rispetto ad un blocco condizionale.
+Tutto ciò fornisce un utile meccanismo di fallback che risulta molto più conciso rispetto a un blocco condizionale.
 Si veda come esempio il Listato 2-16.
 
 Listato 2-16 - Utilizzo del valore predefinito 
 
     [php]
-    // Il parametro 'foobar' non è definito, il metodo getter ritorna un valore nullo
+    // Il parametro 'foobar' non è definito, il metodo getter restituisce un valore nullo
     echo $request->getParameter('foobar');
      => null
 
@@ -773,7 +772,7 @@ Listato 2-17 - Utilizzo dei namespace con il contenitore dei parametri di `sfUse
 
 È possibile aggiungere un contenitore dei parametri a delle classi personalizzate per trarre vantaggio da questo meccanismo
 
-Listato 2-18 - Aggiungere un contenitore dei parametri ad una classe
+Listato 2-18 - Aggiungere un contenitore dei parametri a una classe
 
     [php]
     class MyClass
@@ -815,33 +814,33 @@ Il capitolo 5 illustra i metodi di `sfConfig` nel dettaglio.
 ### Caricamento automatico delle classi
 
 Solitamente in PHP quando viene invocato un metodo di una classe o viene creato un oggetto c'è la necessità di includere per prima cosa 
-la definizione di tale clasee:
+la definizione di tale classe:
 
     [php]
     include_once 'classes/MyClass.php';
     $myObject = new MyClass();
 
-In un progetto di grosse dimensione con molte classi e una profonda e articolata struttura di directory, tener traccia di tutti i file delle vari classi e i percorsi delle stesse può diventare una perdita di tempo.
-Symfony fornisce una funzione `spl_autoload_register()` che rende sueprfluo l'utilizzo della direttiva `include_once`, e che permette di scrivere direttamente:
+In un progetto di grosse dimensione con molte classi e una profonda e articolata struttura di cartelle, tener traccia di tutti i file delle vari classi e i percorsi delle stesse può diventare una perdita di tempo.
+Symfony fornisce una funzione `spl_autoload_register()` che rende superfluo l'utilizzo della direttiva `include_once`, e che permette di scrivere direttamente:
 
     [php]
     $myObject = new MyClass();
 
-Symfony cercherà all'interno delle directory `lib/' la definizione della classe `MyClass` in tutti file che termineranno con `class.php`.
+Symfony cercherà all'interno delle cartelle `lib/' la definizione della classe `MyClass` in tutti file che termineranno con `class.php`.
 Se la classe verrà trovata, verrà inclusa automaticamente.
 
-Collocando le proprie classi all'interno delle directory `lib/' non sarà più necessario includerle.
+Collocando le proprie classi all'interno delle cartelle `lib/' non sarà più necessario includerle.
 Questo è il motivo per il quale solitamente i progetti symfony non contengono direttive `include_once` o `require_once`.
 
 Sommario
--------
+--------
 
-L'utilizzo di un framework MVC obbliga lo sviluppatore ad organizzare il codice in accordo con le convenzioni del framework stesso.
-Il codice di presentazione appartiene alla vista, la manipolazione dei dati appartiene al modello, e la logica della request appartiene al controllore.
+L'utilizzo di un framework MVC obbliga lo sviluppatore a organizzare il codice in accordo con le convenzioni del framework stesso.
+Il codice di presentazione appartiene alla vista, la manipolazione dei dati appartiene al modello, e la logica della richiesta appartiene al controllore.
 
 Symfony è un framework MVC scritto in PHP.
 La sua struttura permette di ottenere il meglio grazie all'utilizzo del pattern MVC, mantenendo al contempo una praticità e semplicità d'utilizzo.
 Grazie alla sua versatilità e configurabilità, symfony è adatto per tutte le tipologie di applicativi web.
 
-Ora che è stata mostrata la teoria alla base di symfony si è in grado di sviluppare una prima applicazione, ma prima di questo occorre un'installazione di symf ony e un
-server di sviluppo.
\ No newline at end of file
+Ora che è stata mostrata la teoria alla base di symfony, si è in grado di sviluppare una prima applicazione, ma prima di questo occorre un'installazione di symfony e un
+server di sviluppo.
diff --git a/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown b/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
index 47a30af..1a5d688 100644
--- a/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
+++ b/gentle-introduction/it/04-The-Basics-of-Page-Creation.markdown
@@ -24,7 +24,7 @@ La riga di comando di symfony automatizza la creazione di moduli. Basta eseguire
     >> tokens    ~/mioprogetto/apps/frontend/modules/contenuto/actions/actions.class.php
     >> tokens    ~/mioprogetto/apps/frontend/modules/contenuto/templates/indexSuccess.php
 
-A parte le cartelle `actions/` e `templates/`, questo comando crea solo tre file. Il primo si trova nella cartella `test/`, riguarda i test funzionali e non si ha bisogno di farci caso fino al Capitolo 15. `actions.class.php` (mostrato nel Listato 4-1) esegue il forward al modulo predefinito con la pagina di congratulazioni. Il file `templates/indexSuccess.php` è vuoto.
+A parte le cartelle `actions/` e `templates/`, questo comando crea solo tre file. Il primo si trova nella cartella `test/`, riguarda i test funzionali e non si ha bisogno di farci caso fino al capitolo 15. `actions.class.php` (mostrato nel Listato 4-1) esegue il forward al modulo predefinito con la pagina di congratulazioni. Il file `templates/indexSuccess.php` è vuoto.
 
 Listato 4-1 - L'azione predefinita generata in `actions/actions.class.php`
 
@@ -104,7 +104,7 @@ symfony si lamenterà per il fatto che manca il template `showSuccess.php`. È n
 >
 >     http://localhost/articles/tagged/finance+france+euro
 >
->Symfony sa come fare il parse e generare URL intelligenti per l'utente. Il sistema per le rotte estrapola automaticamente i parametri della richiesta da una URL intelligente e li rende disponibili all'azione. Formatta anche i link inclusi nella risposta in modo che vengano mostrati in modo "intelligente". Per saperne di più su questa caratteristica, leggere il Capitolo 9.
+>Symfony sa come fare il parse e generare URL intelligenti per l'utente. Il sistema per le rotte estrapola automaticamente i parametri della richiesta da una URL intelligente e li rende disponibili all'azione. Formatta anche i link inclusi nella risposta in modo che vengano mostrati in modo "intelligente". Per saperne di più su questa caratteristica, leggere il capitolo 9.
 >
 >Nel complesso, questo significa che il modo in cui si dà un nome alle azioni delle applicazioni non dovrebbe essere influenzato dal modo in cui scegliamo l'URL per chiamarli, ma dalle funzioni delle azioni nell'applicazione. Il nome di una azione deve descrivere cosa fa l'azione reale e spesso è spesso un verbo in forma all'infinito (come `show`, `list`, `edit` e così via). I nomi delle azioni possono essere del tutto invisibili all'utente finale, quindi non bisogna aver paura di utilizzare nomi di azioni espliciti (come `listByName` or `showWithComments`). In questo modo si può risparmiare sui commenti del codice atti a spiegare la funzione dell'azione e inoltre il codice sarà molto più facile da leggere.
 
@@ -208,7 +208,7 @@ Listato 4-9 - Gli helper `link_to()` e `url_for()`
 
 L'HTML risultante sarà lo stesso del precedente, eccetto che quando si cambiano le regole delle rotte, tutti i template si comporteranno correttamente e riformatteranno gli URL di conseguenza.
 
-L'utilizzo dei form merita un capitolo a sé stante, dato che symfony fornisce molti strumenti per renderli ancora più facili. Si imparerà di più su questi helper nel Capitolo 10.
+L'utilizzo dei form merita un capitolo a sé stante, dato che symfony fornisce molti strumenti per renderli ancora più facili. Si imparerà di più su questi helper nel capitolo 10.
 
 L'helper `link_to()`, così come altri helper, accetta un altro parametro per opzioni speciali e addizionali attributi per i tag. Il Listato 4-10 mostra un esempio di opzioni passate come parametro e dell'HTML risultante. Le opzioni possono essere sia un array associativo che una semplice stringa con coppie `chiave=valore` separate da spazi.
 
@@ -237,7 +237,7 @@ Ogni volta che si utilizza un helper di symfony che genera un tag HTML, è possi
 >**NOTE**
 >Essendo necessaria una ulteriore analisi e trasformazione, la sintassi con stringa è un po' più lenta della sintassi con gli array.
 
-Come tutti gli helper di symfony, gli helper per i link sono numerosi e hanno molte opzioni. Il Capitolo 9 li descrive in dettaglio.
+Come tutti gli helper di symfony, gli helper per i link sono numerosi e hanno molte opzioni. Il capitolo 9 li descrive in dettaglio.
 
 Ottenere informazioni dalla Request
 -----------------------------------
diff --git a/gentle-introduction/it/05-Configuring-Symfony.markdown b/gentle-introduction/it/05-Configuring-Symfony.markdown
index d242ef6..a0069f3 100644
--- a/gentle-introduction/it/05-Configuring-Symfony.markdown
+++ b/gentle-introduction/it/05-Configuring-Symfony.markdown
@@ -31,7 +31,7 @@ Tenendo conto di questi svantaggi, symfony utilizza file di configurazione solo
 
 ### Sintassi YAML e convenzioni di symfony
 
-Per la sua configurazione, symfony utilizza il formato YAML, invece dei più tradizionali INI e XML. YAML mostra la struttura tramite indentazione ed è veloce da scrivere. I vantaggi e le regole di base sono già state mostrate nel Capitolo 1. Comunque, occorre tenere a mente qualche convenzione quando si scrivono file YAML. Questa sezione introduce diverse convenzioni tra le più importanti. Per approfondimenti, visitare il [sito web di YAML](http://www.yaml.org/).
+Per la sua configurazione, symfony utilizza il formato YAML, invece dei più tradizionali INI e XML. YAML mostra la struttura tramite indentazione ed è veloce da scrivere. I vantaggi e le regole di base sono già state mostrate nel capitolo 1. Comunque, occorre tenere a mente qualche convenzione quando si scrivono file YAML. Questa sezione introduce diverse convenzioni tra le più importanti. Per approfondimenti, visitare il [sito web di YAML](http://www.yaml.org/).
 
 Prima di tutto non sono ammessi caratteri di tabulazione in YAML: occorre usare spazi vuoti. I parser YAML non capiscono le tabulazioni, per cui si devono utilizzare spazi vuoti per l'indentazione (la convenzione in symfony è di due spazi), come mostrato nel Listato 5-1.
 
@@ -162,7 +162,7 @@ Listato 5-10 - Gli header di categoria esistono solo per una questione di leggib
 >
 >YAML è solo un'interfaccia per definire impostazioni utilizzate da PHP, per cui le configurazioni YAML finiscono per essere trasformate in PHP. Dopo aver navigato la propria applicazione, se ne può controllare la configurazione in cache (ad esempio in cache/frontend/dev/config/). Si vedranno file PHP corrispondenti alle configurazioni YAML. Altre informazioni sulla cache di configurazione sono disponibili più avanti in questo capitolo.
 >
->La buona notizia è che se non si vuole usare YAML, si può fare la stessa cosa a mano in PHP o con altri formati (come XML o INI). Nel corso di questo libro, vedremo modi alternativi per definire configurazioni senza YAML e impareremo anche come sostituire il gestore di configurazioni di symfony (nel Capitolo 19). Usati largamente, questi trucchi permetteranno di aggirare i file di configurazione o definire il proprio personale formato di configurazione.
+>La buona notizia è che se non si vuole usare YAML, si può fare la stessa cosa a mano in PHP o con altri formati (come XML o INI). Nel corso di questo libro, vedremo modi alternativi per definire configurazioni senza YAML e impareremo anche come sostituire il gestore di configurazioni di symfony (nel capitolo 19). Usati largamente, questi trucchi permetteranno di aggirare i file di configurazione o definire il proprio personale formato di configurazione.
 
 ### Aiuto, un file YAML ha ucciso l'applicazione!
 
@@ -203,16 +203,16 @@ Se la propria applicazione smette improvvisamente di funzionare dopo un cambio d
 Riepilogo sui file di configurazione
 ------------------------------------
 
-La configurazione è suddivisa in file, per oggetto. Questi file contengono definizioni di parametri o impostazioni. Alcuni di tali parametri possono essere sovrascritti a diversi livelli (progetto, applicazione e modulo), altri sono specifici di un certo livello. I prossimi capitoli prenderanno in esame le configurazioni relativamente alle loro finalità principali, mentre il Capitolo 19 esaminerà le configurazioni avanzate.
+La configurazione è suddivisa in file, per oggetto. Questi file contengono definizioni di parametri o impostazioni. Alcuni di tali parametri possono essere sovrascritti a diversi livelli (progetto, applicazione e modulo), altri sono specifici di un certo livello. I prossimi capitoli prenderanno in esame le configurazioni relativamente alle loro finalità principali, mentre il capitolo 19 esaminerà le configurazioni avanzate.
 
 ### Configurazione di progetto
 
 Ci sono pochi file di configurazione predefiniti per il progetto. Di seguito quelli che si trovano nella cartella `progetto/config/`:
 
-  * `ProjectConfiguration.class.php`: Questo è assolutamente il primo file incluso da ogni richiesta o comando. Contiene i percorsi ai file del framework e può essere cambiato per usare un'installazione diversa. Vedere il Capitolo 19 per usi avanzati di questo file.
-  * `databases.yml`: Qui è dove si definisce l'accesso e la connessione al database (host, login, password, nome del database e così via). Vedremo di più su questo nel Capitolo 8. Può essere sovrascritto a livello di applicazione.
-  * `properties.ini`: Questo file gestisce parametri utilizzati a linea di comando, inclusi il nome del progetto e le impostazioni di connessione a server remoti. Vedere il Capitolo 16 per un sommario delle caratteristiche di utilizzo di questo file.
-  * `rsync_exclude.txt`: Questo file specifica quali cartelle e file devono essere esclusi dalla sincronizzazione tra server. È discusso nel Capitolo 16.
+  * `ProjectConfiguration.class.php`: Questo è assolutamente il primo file incluso da ogni richiesta o comando. Contiene i percorsi ai file del framework e può essere cambiato per usare un'installazione diversa. Vedere il capitolo 19 per usi avanzati di questo file.
+  * `databases.yml`: Qui è dove si definisce l'accesso e la connessione al database (host, login, password, nome del database e così via). Vedremo di più su questo nel capitolo 8. Può essere sovrascritto a livello di applicazione.
+  * `properties.ini`: Questo file gestisce parametri utilizzati a linea di comando, inclusi il nome del progetto e le impostazioni di connessione a server remoti. Vedere il capitolo 16 per un sommario delle caratteristiche di utilizzo di questo file.
+  * `rsync_exclude.txt`: Questo file specifica quali cartelle e file devono essere esclusi dalla sincronizzazione tra server. È discusso nel capitolo 16.
   * `schema.yml`: Si tratta del file di configurazione per l'accesso ai dati usato da Propel e Doctrine (gli ORM di symfony). Esso è usato per far funzionare le librerie dell'ORM con le classi di symfony e i dati del progetto. Il file `schema.yml` contiene una rappresentazione del modello relazionale del progetto. Per Doctrine, il file è in `config/doctrine/`.
 
 Questi file sono usati per lo più da componenti esterni o dalla linea di comando o devono essere processati prima che il framework carichi il programma di analisi YAML. Ecco perché alcuni di essi non usano il formato YAML.
@@ -239,7 +239,7 @@ Dopo aver definito il nome dell'applicazione (`frontend`), l'ambiente (`prod`) e
   * `$configuration->getRootDir()`: La cartella radice del progetto (di norma dovrebbe rimanere come è, a meno che non si voglia cambiare la struttura delle cartelle). 
   * `$configuration->getApplication()`: Nome dell'applicazione nel progetto. Necessario per calcolare i percorsi dei file.
   * `$configuration->getEnvironment()`: Nome dell'ambiente (`prod`, `dev` o qualsiasi altro ambiente specifico creato ad hoc per il progetto). Determinerà quali sono le impostazioni di configurazione da utilizzare. Gli ambienti sono spiegati più avanti in questo capitolo. 
-  * `$configuration->isDebug()`: Attivazione della modalità di debug (vedere il Capitolo 16 per i dettagli). 
+  * `$configuration->isDebug()`: Attivazione della modalità di debug (vedere il capitolo 16 per i dettagli). 
 
 Se si vuole cambiare uno di questi valori, probabilmente occorrerà di un front controller addizionale. Il prossimo capitolo spiegherà più nel dettaglio i front controller e come crearne di nuovi. 
 
@@ -248,12 +248,12 @@ Se si vuole cambiare uno di questi valori, probabilmente occorrerà di un front
 La configurazione dell'applicazione principale è memorizzata in file che si trovano nella cartella `progetto/apps/frontend/config/`: 
 
   * `app.yml`: Questo file dovrebbe contenere configurazioni specifiche all'applicazione; ad esempio variabili globali che definiscono business logic, che non hanno bisogno di essere memorizzate nel db. Tasse, costi di spedizione, indirizzi e-mail sono memorizzati spesso in questo file, che di base è vuoto.
-  * `frontendConfiguration.class.php`: questa classe si occupa del bootstrap dell'applicazione, quindi fa tutte le inizializzazioni di base necessarie all'applicazione per partire. È qui che si può definire una struttura di cartelle particolare, oppure delle costanti specifiche (il Capitolo 19 ne fornirà maggiori dettagli). Estende la classe `ProjectConfiguration`. 
-  * `factories.yml`: symfony definisce le proprie classi per gestire le viste, la richiesta, la risposta, le sessioni e così via. Se invece si vogliono utilizzare le proprie classi personali, questo file è i posto in cui definirle (maggiori informazioni nel Capitolo 17). 
-  * `filters.yml`: I filtri sono porzioni di codice eseguiti per ogni richiesta. Qui è dove definisci quali filtri devono essere processati, e può essere sovrascritto in ogni modulo. Il Capitolo 6 fornisce maggiori dettagli sui filtri. 
-  * `routing.yml`: Le regole di routing, che permettono di trasformare un URL illeggibile in uno più "intelligente", sono definite in questo file. Per nuove applicazioni, esistono poche regole predefinite. Il Capitolo 9 è dedicato ai link e al routing.
-  * `settings.yml`: Le impostazioni principali di un'applicazione symfony sono definiti in questo file. Qui si specifica se la propria applicazione è internazionalizzata, qual è la lingua di default, il timeout per le richieste e se la cache è attiva o meno. Cambiando una linea di questo file si può "spegnere" la propria applicazione, per poterla aggiornare o manutenere. Le impostazioni più comuni e il loro utilizzo sono approfonditi nel Capitolo 19. 
-  * `view.yml`: La struttura predefinita della vista (nome del layout, fogli di stile e JavaScript da includere di default, content-type di default e così via) è definita in questo file. Il Capitolo 7 approfondirà questo file. Queste impostazioni possono essere sovrascritte in ogni modulo. 
+  * `frontendConfiguration.class.php`: questa classe si occupa del bootstrap dell'applicazione, quindi fa tutte le inizializzazioni di base necessarie all'applicazione per partire. È qui che si può definire una struttura di cartelle particolare, oppure delle costanti specifiche (il capitolo 19 ne fornirà maggiori dettagli). Estende la classe `ProjectConfiguration`. 
+  * `factories.yml`: symfony definisce le proprie classi per gestire le viste, la richiesta, la risposta, le sessioni e così via. Se invece si vogliono utilizzare le proprie classi personali, questo file è i posto in cui definirle (maggiori informazioni nel capitolo 17). 
+  * `filters.yml`: I filtri sono porzioni di codice eseguiti per ogni richiesta. Qui è dove definisci quali filtri devono essere processati, e può essere sovrascritto in ogni modulo. Il capitolo 6 fornisce maggiori dettagli sui filtri. 
+  * `routing.yml`: Le regole di routing, che permettono di trasformare un URL illeggibile in uno più "intelligente", sono definite in questo file. Per nuove applicazioni, esistono poche regole predefinite. Il capitolo 9 è dedicato ai link e al routing.
+  * `settings.yml`: Le impostazioni principali di un'applicazione symfony sono definiti in questo file. Qui si specifica se la propria applicazione è internazionalizzata, qual è la lingua di default, il timeout per le richieste e se la cache è attiva o meno. Cambiando una linea di questo file si può "spegnere" la propria applicazione, per poterla aggiornare o manutenere. Le impostazioni più comuni e il loro utilizzo sono approfonditi nel capitolo 19. 
+  * `view.yml`: La struttura predefinita della vista (nome del layout, fogli di stile e JavaScript da includere di default, content-type di default e così via) è definita in questo file. Il capitolo 7 approfondirà questo file. Queste impostazioni possono essere sovrascritte in ogni modulo. 
 
 >**TIP**
 >Tutti i file di configurazione di symfony sono descritti in dettaglio nella [Guida di riferimento a symfony](http://www.symfony-project.org/reference/1_4/it/).
@@ -265,15 +265,15 @@ Applicazioni internazionalizzate possono mostrare le pagine in diverse lingue. Q
   * `factories.yml` della cartella `config/` dell'applicazione: Questo file definisce il factory i18n e le opzioni generali di traduzione, come ad esempio la cultura predefinita per la traduzione, se le traduzioni sono in un file o nel database e il loro formato. 
   * File di traduzione nella cartella `i18n/` dell'applicazione: Questi sono fondamentalmente dei dizionari, che forniscono la traduzione delle parole utilizzate nelle template dell'applicazione in modo che le pagine mostrino testo tradotto quando un utente cambia la lingua.
   
-Nota che l'attivazione delle feature i18n è impostata nel file `settings.yml`. Approfondimenti a tale proposito nel Capitolo 13.
+Nota che l'attivazione delle feature i18n è impostata nel file `settings.yml`. Approfondimenti a tale proposito nel capitolo 13.
 
 #### Configurazioni addizionali dell'applicazione
 
 Un secondo insieme di file di configurazione è posizionato nella cartella di installazione di symfony in `sfConfig::get('sf_symfony_lib_dir')/config/config/`) e non figura nella cartella di configurazione delle applicazioni. Tali impostazioni raramente hanno bisogno di essere modificate, oppure sono globali a tutti i progetti. Comunque, se si avesse bisogno di modificarle, creare un file vuoto nella cartella `progetto/apps/frontend/config/` e sovrascrivere i parametri da cambiare. Le impostazioni definite nell'applicazione hanno sempre la precedenza rispetto a quelle definite nel framework. Di seguito, i file di configurazione nella cartella `config/` dell'installazione di symfony: 
 
-  * `autoload.yml`: Questo file contiene le impostazioni della funzione di autoloading. Tale funzione ti esonera dall'includere classi personalizzate se esse si trovano in una cartella specifica. Questa funzione è descritta nel Capitolo 19.
-  * `core_compile.yml`: Queste sono liste di classi da includere per far partire un'applicazione. Queste classi vengono poi concatenate in un file PHP ottimizzato senza commenti, che velocizzerà l'esecuzione minimizzando le operazioni di accesso (è caricato un solo file invece di quaranta per ogni richiesta). Questo risulta specialmente utile se non utilizzi un acceleratore PHP. Le tecniche di ottimizzazione sono descritte nel Capitolo 18. 
-  * `config_handlers.yml`: Qui si possono aggiungere o modificare i gestori usati per processare ogni file di configurazione. Il Capitolo 19 fornisce maggiori dettagli in merito.
+  * `autoload.yml`: Questo file contiene le impostazioni della funzione di autoloading. Tale funzione ti esonera dall'includere classi personalizzate se esse si trovano in una cartella specifica. Questa funzione è descritta nel capitolo 19.
+  * `core_compile.yml`: Queste sono liste di classi da includere per far partire un'applicazione. Queste classi vengono poi concatenate in un file PHP ottimizzato senza commenti, che velocizzerà l'esecuzione minimizzando le operazioni di accesso (è caricato un solo file invece di quaranta per ogni richiesta). Questo risulta specialmente utile se non utilizzi un acceleratore PHP. Le tecniche di ottimizzazione sono descritte nel capitolo 18. 
+  * `config_handlers.yml`: Qui si possono aggiungere o modificare i gestori usati per processare ogni file di configurazione. Il capitolo 19 fornisce maggiori dettagli in merito.
   
 ### Configurazione del modulo
 
@@ -281,10 +281,10 @@ Per impostazione predefinita, un modulo non ha una configurazione specifica. Ma,
 
 Come si può immaginare, le impostazioni di un modulo devono essere nella cartella `progetto/apps/frontend/modules/mymodule/config/`. I file interessati sono i seguenti: 
 
-  * `generator.yml`: Per i moduli generati secondo una tabella di database (scaffolding e amministrazione), questo file descrive il modo in cui le righe e campi devono essere visualizzati e quali tipi di interazioni sono proposti all'utente (filtri, ordinamenti, pulsanti e così via). Il Capitolo 14 approfondirà l'argomento. 
-  * `module.yml`: Questo file contiene parametri specifici per un modulo (equivalente a `app.yml`, ma a livello di modulo) e la configurazione dell'azione. Il Capitolo 6 fornisce maggiori dettagli in merito.
-  * `security.yml`: Questo file permette di impostare restrizioni per le azioni. Qui si può impostare il fatto che una certa pagina sia visibile solo agli utenti registrati, oppure a un sottoinsieme di utenti con permessi speciali. Il Capitolo 6 fornisce maggiori dettagli in merito. 
-  * `view.yml`: Questo file contiene le configurazioni delle viste di una o tutte le azioni di un modulo. Permette di sovrascrivere `view.yml` del livello dell'applicazione ed è descritto nel Capitolo 7. 
+  * `generator.yml`: Per i moduli generati secondo una tabella di database (scaffolding e amministrazione), questo file descrive il modo in cui le righe e campi devono essere visualizzati e quali tipi di interazioni sono proposti all'utente (filtri, ordinamenti, pulsanti e così via). Il capitolo 14 approfondirà l'argomento. 
+  * `module.yml`: Questo file contiene parametri specifici per un modulo (equivalente a `app.yml`, ma a livello di modulo) e la configurazione dell'azione. Il capitolo 6 fornisce maggiori dettagli in merito.
+  * `security.yml`: Questo file permette di impostare restrizioni per le azioni. Qui si può impostare il fatto che una certa pagina sia visibile solo agli utenti registrati, oppure a un sottoinsieme di utenti con permessi speciali. Il capitolo 6 fornisce maggiori dettagli in merito. 
+  * `view.yml`: Questo file contiene le configurazioni delle viste di una o tutte le azioni di un modulo. Permette di sovrascrivere `view.yml` del livello dell'applicazione ed è descritto nel capitolo 7. 
 
 La maggior parte dei file di configurazione dei moduli offrono la possibilità di definire parametri per tutte le viste o tutte le azioni di un modulo, oppure per un loro sottoinsieme. 
 
@@ -521,7 +521,7 @@ Listato 5-18 - Ciò che symfony produce quando analizza `settings.yml`
       'sf_escaping_method' => 'ESC_SPECIALCHARS',
     ));
 
-Il significato dei parametri del file `settings.yml` è spiegato nel Capitolo 19.
+Il significato dei parametri del file `settings.yml` è spiegato nel capitolo 19.
 
 ### Impostazioni dell'applicazione personalizzati e `app.yml`
 
@@ -570,7 +570,7 @@ Per sapere se una carta di credito è accettata nell'ambiente corrente, controll
 >**TIP**
 >Ogni qualvolta si è tentati di definire una costante o un parametro in uno script, considerare se non possa essere meglio metterlo nel file `app.yml`. È un posto molto conveniente per memorizzare i parametri dell'applicazione.
 
-Quando servono parametri personalizzati e diventa difficile utilizzare la sintassi di `app.yml`, si può definire una propria sintassi personalizzata. In questo caso, si può memorizzare la configurazione in un nuovo file, interpretato da un nuovo gestore. Il Capitolo 19 fornisce maggiori informazioni sui gestori di configurazione. 
+Quando servono parametri personalizzati e diventa difficile utilizzare la sintassi di `app.yml`, si può definire una propria sintassi personalizzata. In questo caso, si può memorizzare la configurazione in un nuovo file, interpretato da un nuovo gestore. Il capitolo 19 fornisce maggiori informazioni sui gestori di configurazione. 
 
 Suggerimenti per ottenere di più dai file di configurazione
 -----------------------------------------------------------
diff --git a/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown b/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
index f86f0c2..2649566 100644
--- a/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
+++ b/gentle-introduction/it/06-Inside-the-Controller-Layer.markdown
@@ -203,7 +203,7 @@ Listing 6-7 - Metodi comuni `sfActions`
 >**SIDEBAR**
 >Il singleton context
 >
->Abbiamo già visto, nel front controller, una chiamata a `sfContext::createInstance()`. Nell'azione il metodo `getContext()` ritorna lo stesso singleton. Questo è un oggetto molto utile che contiene una referenza a tutti gli oggetti del core di symfony associati a una richiesta mettendo a disposizione una via di accesso a ognuno di loro:
+>Abbiamo già visto, nel front controller, una chiamata a `sfContext::createInstance()`. Nell'azione il metodo `getContext()` restituisce lo stesso singleton. Questo è un oggetto molto utile che contiene un riferimento a tutti gli oggetti del nocciolo di symfony associati a una richiesta, mettendo a disposizione una via di accesso a ognuno di loro:
 >
 >`sfController`: L'oggetto controllore (`->getController()`)
 >
@@ -227,7 +227,7 @@ Listing 6-7 - Metodi comuni `sfActions`
 
 ### Terminare l'azione
 
-Alla fine dell'esecuzione di un'azione si possono assumere diversi comportamenti. Il valore ritornato dal metodo dell'azione determina come la vista verrà generata. Le costanti della classe `sfView` vengono utilizzate per specificate quale template utilizzare per mostrare il risultato dell'azione.
+Alla fine dell'esecuzione di un'azione si possono assumere diversi comportamenti. Il valore restituito dal metodo dell'azione determina come la vista verrà generata. Le costanti della classe `sfView` vengono utilizzate per specificate quale template utilizzare per mostrare il risultato dell'azione.
 
 Se esiste una vista predefinita da invocare (questo è il caso più comune), l'azione dovrebbe terminare come segue:
 
@@ -267,9 +267,9 @@ Nel caso in cui non esista una vista da chiamare--per esempio nel caso in cui un
     [php]
     return sfView::NONE;
 
-Nessun template verrà eseguito in questo caso. Significa che è possibile aggirare completamente il livello della vista e impostare il codice HTML di risposta direttamente in un'azione. Come mostrato nel listato 6-9, symfony mette a disposizione uno specifico metodo `renderText()` per questo caso. Può essere utile quando si ha bisogno di un'azione estremamente responsiva, come per le interazioni Ajax, che verranno affrontate nel Capitolo 11.
+Nessun template verrà eseguito in questo caso. Significa che è possibile aggirare completamente il livello della vista e impostare il codice HTML di risposta direttamente in un'azione. Come mostrato nel listato 6-9, symfony mette a disposizione uno specifico metodo `renderText()` per questo caso. Può essere utile quando si ha bisogno di un'azione estremamente responsiva, come per le interazioni Ajax, che verranno affrontate nel capitolo 11.
 
-Listing 6-9 - Aggirare la vista facendo l'echo della risposta e ritornando `sfView::NONE`
+Listing 6-9 - Aggirare la vista facendo l'echo della risposta e restituendo `sfView::NONE`
 
     [php]
     public function executeIndex()
@@ -587,7 +587,7 @@ Listing 6-18 - Cambiare server session storage, in `apps/frontend/config/factori
           db_data_col: sess_data            # Name of the column storing the session data
           db_time_col: sess_time            # Name of the column storing the session timestamp
 
-L'impostazione `database` definisce quale connessione al database utilizzare. Symfony userà così `databases.yml` (vedere Capitolo 8) per determinare i parametri di connessione (host, nome database, utente e password).
+L'impostazione `database` definisce quale connessione al database utilizzare. Symfony userà così `databases.yml` (vedere capitolo 8) per determinare i parametri di connessione (host, nome database, utente e password).
 
 La classi disponibili per il session storage sono `sfCacheSessionStorage`, `sfMySQLSessionStorage`, `sfMySQLiSessionStorage`, `sfPostgreSQLSessionStorage` e `sfPDOSessionStorage`; l'ultima è quella da preferire. Per disabilitare totalmente il session storage si può utilizzaree la classe `sfNoStorage`.
 
@@ -601,7 +601,7 @@ Listing 6-19 - Modificare la durata delle sessioni, in `apps/frontend/config/fac
         param:
           timeout:   1800           # Durata delle sessioni in secondi
 
-Per conoscere più a fondo i factory fare riferimento al Capitolo 19.
+Per conoscere più a fondo i factory fare riferimento al capitolo 19.
 
 Sicurezza delle azioni
 ----------------------
@@ -727,7 +727,7 @@ Listing 6-24 - Lavorare con le credenziali utenti in un template
 Come per lo stato di autenticato le credenziali sono spesso assegnate all'utente durante il processo di login. Ecco perché l'oggetto `sfUser` viene spesso esteso per aggiungere i metodi di login e logout in modo da impostare lo stato di sicurezza in un posto centralizzato.
 
 >**TIP**
->Tra i plugin di symfony [`sfGuardPlugin`](http://www.symfony-project.org/plugins/sfGuardPlugin) e [`sfDoctrineGuardPlugin`](http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin) estendono la classe della sessione per semplificare login e logout. Fare riferimento al Capitolo 17 per maggiori informazioni.
+>Tra i plugin di symfony [`sfGuardPlugin`](http://www.symfony-project.org/plugins/sfGuardPlugin) e [`sfDoctrineGuardPlugin`](http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin) estendono la classe della sessione per semplificare login e logout. Fare riferimento al capitolo 17 per maggiori informazioni.
 
 ### Credenziali complesse
 
@@ -961,7 +961,7 @@ Listing 6-33 - Filtro per comunicazione sicura
       }
     }
 
-I filtri vengono utilizzati in modo massivo nel plug-in visto che permettono di estendere le funzionalità di un'applicazione in modo completo. Fare riferimento al Capitolo 17 per saperne di più sui plugin.
+I filtri vengono utilizzati in modo massivo nel plug-in visto che permettono di estendere le funzionalità di un'applicazione in modo completo. Fare riferimento al capitolo 17 per saperne di più sui plugin.
 
 Configurazione dei moduli
 -------------------------
diff --git a/gentle-introduction/it/07-Inside-the-View-Layer.markdown b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
index bbe5549..8354089 100644
--- a/gentle-introduction/it/07-Inside-the-View-Layer.markdown
+++ b/gentle-introduction/it/07-Inside-the-View-Layer.markdown
@@ -215,7 +215,7 @@ Per esempio, se molti template dell'applicazione hanno bisogno di utilizzare lo
     [php]
     <?php include(sfConfig::get('sf_app_template_dir').'/mioFrammento.php') ?>
 
-Ma questo non è un modo molto pulito per gestire un frammento, soprattutto perché possono esserci nomi di variabili differenti tra il frammento e i vari template che lo includono. Inoltre, il sistema per la cache di symfony (descritto nel Capitolo 12) non ha modo di rilevare un include, quindi il frammento non può essere messo in cache indipendentemente dal template. Symfony fornisce tre tipi alternativi di frammenti di codice per sostituire gli `include`:
+Ma questo non è un modo molto pulito per gestire un frammento, soprattutto perché possono esserci nomi di variabili differenti tra il frammento e i vari template che lo includono. Inoltre, il sistema per la cache di symfony (descritto nel capitolo 12) non ha modo di rilevare un include, quindi il frammento non può essere messo in cache indipendentemente dal template. Symfony fornisce tre tipi alternativi di frammenti di codice per sostituire gli `include`:
 
   * Se la logica è leggera, basterà includere un file template che ha accesso ad alcuni dati che gli vengono passati. Per questo si userà un partial.
   * Se la logica è più pesante (ad esempio, se è necessario accedere al modello dei dati e/o modificare il contenuto in base alla sessione), è preferibile separare la presentazione dalla logica. Per questo, si userà un component.
@@ -279,7 +279,7 @@ Listato 7-10 - Il partial ora può usare la variabile, in `miomodulo/templates/_
 >Tutti gli helper fin'ora sono stati chiamati da `<?php echo nomeFunzione() ?>`. L'helper partial, però, è chiamato semplicemente da `<?php include_partial() ?>`, senza `echo`, in modo che abbia un comportamento simile al normale comando PHP `include()`. Se si ha bisogno di una funzione che restituisca il contenuto di un partial senza visualizzarlo, utilizzare `get_partial()`. Tutti gli helper `include_` descritti in questo capitolo hanno una controparte `get_` che può essere chiamata insieme al comando `echo`.
 
 >**TIP**
->Invece di visualizzare un template, una azione può restituire un partial o un component. I metodi `renderPartial()` e `renderComponent()` della classe dell'azione promuovono la riusabilità del codice. Inoltre sfruttano la possibilità dei partial di essere messi in cache (vedere il Capitolo 12). Le variabili definite nell'azione verranno passate automaticamente al partial/component, a meno che non si definisca un array associativo di varibili come secondo paramentro del metodo.
+>Invece di visualizzare un template, una azione può restituire un partial o un component. I metodi `renderPartial()` e `renderComponent()` della classe dell'azione promuovono la riusabilità del codice. Inoltre sfruttano la possibilità dei partial di essere messi in cache (vedere il capitolo 12). Le variabili definite nell'azione verranno passate automaticamente al partial/component, a meno che non si definisca un array associativo di varibili come secondo paramentro del metodo.
 >
 >     [php]
 >     public function executeFoo()
@@ -299,7 +299,7 @@ Listato 7-10 - Il partial ora può usare la variabile, in `miomodulo/templates/_
 
 ### Component
 
-Nel Capitolo 2, il primo script di esempio è stato spezzato in due parti per separare la logica dalla presentazione. Proprio come il pattern MVC si applica alle azioni e ai template, può essere necessario dividere un partial in una parte di logica e in una parte di presentazione. In tal caso, è necessario utilizzare un componente. 
+Nel capitolo 2, il primo script di esempio è stato spezzato in due parti per separare la logica dalla presentazione. Proprio come il pattern MVC si applica alle azioni e ai template, può essere necessario dividere un partial in una parte di logica e in una parte di presentazione. In tal caso, è necessario utilizzare un componente. 
 
 Un componente è come una azione, salvo il fatto che è molto più veloce. La logica di un componente è all'interno di una classe che eredita da `sfComponents`, situata in un file `actions/components.class.php`.  La sua presentazione è è messa in un partial. I metodi di una classe `sfComponents` iniziano con la parola `execute`, proprio come le azioni e possono passare variabili ai loro controparti della presentazione nello stesso modo con cui le azioni passano variabili. I partial che vengono utilizzati come presentazione per componenti sono nominati con lo stesso nome del componente (senza l'`execute`, ma con una sottolineatura iniziale). La Tabella 7-1 compara le convenzioni per i nomi per azioni e componenti.
 
@@ -594,7 +594,7 @@ I setter dell'header sono molto potenti in symfony. Gli header sono inviati il p
     echo $response->getContentType();
      => 'text/xml; charset=utf-8'
 
-Il codice di stato delle risposte di symfony è compatibile con la specifica HTTP. Le eccezioni restituiscono uno stato 500, le pagine non trovate restituiscono 404, le pagine normali restituiscono uno stato 200, le pagine non modificate possono essere ridotte a un semplice header con il codice di stato 304 (vedere il Capitolo 12 per maggiori dettagli) e così via. Ma è possibile sovrascrivere questi valori predefiniti impostando il proprio codice di stato nell'azione con il metodo response `setStatusCode()`.  È possibile specificare un codice personalizzato e un messaggio personalizzato, o semplicemente un codice personalizzato, nel qual caso, symfony aggiunge un messaggio generico per questo codice.
+Il codice di stato delle risposte di symfony è compatibile con la specifica HTTP. Le eccezioni restituiscono uno stato 500, le pagine non trovate restituiscono 404, le pagine normali restituiscono uno stato 200, le pagine non modificate possono essere ridotte a un semplice header con il codice di stato 304 (vedere il capitolo 12 per maggiori dettagli) e così via. Ma è possibile sovrascrivere questi valori predefiniti impostando il proprio codice di stato nell'azione con il metodo response `setStatusCode()`.  È possibile specificare un codice personalizzato e un messaggio personalizzato, o semplicemente un codice personalizzato, nel qual caso, symfony aggiunge un messaggio generico per questo codice.
 
     [php]
     $response->setStatusCode(404, 'Questa pagina non esiste');
diff --git a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
index 796c9c5..60f098a 100644
--- a/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
+++ b/gentle-introduction/it/08-Inside-the-Model-Layer-Doctrine.markdown
@@ -6,23 +6,23 @@ Gran parte della trattazione finora è stata dedicata alla costruzione di pagine
 Questo capitolo spiega come creare un modello di dati a oggetti e come accedere ai dati e modificarli con Doctrine. Viene anche trattata l'integrazione di Doctrine con symfony.
 
 >**TIP**
->Se si vuole utilizzare Propel al posto di Doctrine, leggere l'Appendice A che contiene le stesse informazioni ma riferite a Propel.
+>Se si vuole utilizzare Propel al posto di Doctrine, leggere l'Appendice A, che contiene le stesse informazioni ma riferite a Propel.
 
 Perché usare un ORM e un livello per l'astrazione?
 --------------------------------------------------
 
 I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM), ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
 
-Il vantaggio principale di un ORM è la riutilizzabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
+Il vantaggio principale di un ORM è la riusabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
 
-Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo accessor alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
+Usare oggetti al posto di record e classi al posto di tabelle, ha un altro vantaggio: la possibilità di aggiungere agli oggetti nuove funzioni di accesso che non necessariamente corrispondono a una colonna in una tabella. Per esempio, se si ha una tabella chiamata `cliente` con due campi chiamati `nome` e `cognome`, si potrebbe volere la possibilità di chiedere solo il `Nome`. In un mondo orientato agli oggetti, basta aggiungere un nuovo metodo di accesso alla classe `Cliente`, come si può vedere nel Listato 8-1. Dal punto di vista dell'applicativo, non vi è alcuna differenza tra `Nome`, `Cognome`, e `NomePersona`: sono tutti attributi della classe `Cliente`. Solo la classe stessa può determinare quali attributi corrispondono a una colonna del database.
 
-Listato 8-1 - Il metodo accessor maschera la struttura della tabella in una classe del modello
+Listato 8-1 - Il metodo di accesso maschera la struttura della tabella in una classe del modello
 
     [php]
-    public function getNomePersona()
+    public function getName()
     {
-      return $this->getNome().' '.$this->getCognome();
+      return $this->getFirstName().' '.$this->getLastName();
     }
 
 Tutte le funzioni ripetute di accesso ai dati e la business logic dei dati stessi, possono essere tenute in tali oggetti. Supponiamo di avere una classe `ShoppingCart` in cui si tenere gli `Articoli` (che sono oggetti). Per ottenere l'importo totale del carrello della spesa, necessario per il pagamento, bisogna scrivere un metodo personalizzato per incapsulare il calcolo effettivo, come mostrato nel Listato 8-2.
@@ -30,22 +30,22 @@ Tutte le funzioni ripetute di accesso ai dati e la business logic dei dati stess
 Listato 8-2 - Il metodo accessor maschera la logica dei dati
 
     [php]
-    public function getTotale()
+    public function getTotal()
     {
-      $totale = 0;
-      foreach ($this->getArticoli() as $articolo)
+      $total = 0;
+      foreach ($this->getItems() as $item)
       {
-        $totale += $articolo->getPrezzo() * $articolo->getQuantita();
+        $total += $item->getPrice() * $item->getQuantity();
       }
 
-      return $totale;
+      return $total;
     }
 
-C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro DataBase Management System (DBMS) costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale nell'SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del DBMS e di ottimizzare il codice SQL. 
+C'è un altro punto importante da considerare quando si realizzano delle procedure di accesso ai dati: ogni database utilizza una variante diversa di sintassi SQL. Il passaggio a un altro database costringe a riscrivere parte delle query SQL che sono state progettate per quello precedente. Costruendo le query utilizzando una sintassi indipendente dal database e lasciando la traduzione reale del codice SQL a un componente di terze parti, è possibile cambiare il tipo di database senza troppi problemi. Questo è l'obiettivo del livello di astrazione del database. Costringe a usare una sintassi specifica per le query e fa il lavoro sporco di conformarsi alle particolarità del database e di ottimizzare il codice SQL.
 
 Il principale vantaggio del livello di astrazione è la portabilità, perché rende possibile il passaggio a un'altra base di dati, anche nel bel mezzo di un progetto. Si supponga di dover scrivere rapidamente un prototipo per un'applicazione, ma il cliente non ha ancora deciso quale sistema di base dati può essere la più adatto alle sue esigenze. Si può cominciare a costruire l'applicazione con SQLite, per esempio e passare a MySQL, PostgreSQL, Oracle quando il cliente ha fatto la scelta. Per fare il cambiamento, basta cambiare una riga in un file di configurazione. 
 
-Symfony usa Propel o Doctrine come ORM, e questi usano oggetti PHP per l'astrazione dei dati del database. Queste due componenti di terze parti, entrambi sviluppati dal team di Propel e Doctrine, sono perfettamente integrati in symfony, ed è possibile considerarli come parte del framework. La loro sintassi e le loro convenzioni, descritte in questo capitolo, sono state adattate in modo da differenziarsi il meno possibile da quelle di symfony.
+Symfony usa Propel o Doctrine come ORM, e questi usano oggetti PHP per l'astrazione dei dati del database. Queste due componenti di terze parti, entrambi sviluppati dal team di Propel e Doctrine, sono perfettamente integrati in symfony ed è possibile considerarli come parte del framework. La loro sintassi e le loro convenzioni, descritte in questo capitolo, sono state adattate in modo da differenziarsi il meno possibile da quelle di symfony.
 
 >**NOTE**
 >In un progetto symfony, tutte le applicazioni condividono lo stesso modello. Questo è un punto fondamentale a livello di progetto: raggruppare le applicazioni che si basano su regole di business comuni. Questa è la ragione per cui il modello è indipendente dalle applicazioni e i file del modello sono memorizzati in una cartella `lib/model/` nella radice del progetto.
@@ -59,8 +59,7 @@ La sintassi di symfony per gli schemi utilizza il formato YAML. I file `schema.y
 
 ### Esempio di schema
 
-Come tradurre la struttura del database in uno schema? Un esempio è il modo migliore per capirlo. Immaginiamo di avere il database di un blog con due tabelle:
- `blog_articolo` e `blog_commento`, con la struttura mostrata in Figura 8-1.
+Come tradurre la struttura del database in uno schema? Un esempio è il modo migliore per capirlo. Immaginiamo di avere il database di un blog con due tabelle: `blog_articolo` e `blog_commento`, con la struttura mostrata in Figura 8-1.
 
 Figura 8-1 - Struttura delle tabelle del database di un blog
 
@@ -71,30 +70,30 @@ Il relativo file `schema.yml` dovrebbe apparire come nel Listato 8-3.
 Listato 8-3 - Esempio di file `schema.yml`
 
     [yml]
-    Articolo:
+    Article:
       actAs: [Timestampable]
-      tableName: blog_articolo
+      tableName: blog_article
       columns:
         id:
           type: integer
           primary: true
           autoincrement: true
-        titolo:   string(255)
-        contenuto: clob
+        title:   string(255)
+        content: clob
     
-    Commento:
+    Comment:
       actAs: [Timestampable]
-      tableName: blog_commento
+      tableName: blog_comment
       columns:
         id:
           type: integer
           primary: true
           autoincrement: true
-        articolo_id: integer
-        autore: string(255)
-        contenuto: clob
+        article_id: integer
+        author: string(255)
+        content: clob
       relations:
-        Articolo:
+        Article:
           onDelete: CASCADE
           foreignAlias: Comments
 
@@ -107,7 +106,7 @@ In un file `schema.yml`, la prima chiave rappresenta un nome del modello. È pos
 Un modello può avere attributi speciali, tra cui la `tableName` (il nome della tabella del database relativa al modello). Se non si specifica la `tableName` per un modello, Doctrine lo crea facendo una versione con sottolineatura del nome del modello. 
 
 >**TIP**
->La convenzione della sottolineatura aggiunge sottolineature tra le parole e utilizza solo caratteri minuscoli. Le versioni sottolineate predefinite di `Articolo` e `Commento` sono `articolo` e `commento`.
+>La convenzione della sottolineatura aggiunge sottolineature tra le parole e utilizza solo caratteri minuscoli. Le versioni sottolineate predefinite di `Article` e `Comment` sono `article` e `comment`.
 
 Un modello contiene colonne. Il valore della colonna può essere definito in due modi diversi:
 
@@ -129,15 +128,15 @@ Lo schema è usato per costruire le classi del modello nel livello ORM. Per risp
 
 La digitazione del comando lancerà l'analisi dello schema e la generazione delle classe base del modello dei dati nella cartella `lib/model/doctrine/base` del progetto:
 
-  * `BaseArticolo.php`
-  * `BaseCommento.php`
+  * `BaseArticle.php`
+  * `BaseComment.php`
 
 Inoltre nella cartella `lib/model/doctrine` verranno create le classi personalizzate del modello :
 
-  * `Articolo.php`
-  * `ArticoloTable.php`
-  * `Commento.php`
-  * `CommentoTable.php`
+  * `Article.php`
+  * `ArticleTable.php`
+  * `Comment.php`
+  * `CommentTable.php`
 
 Sono stati definiti solo due modelli e ci si ritrova con sei file. Non c'è nulla di sbagliato, ma questo risultato merita una ulteriore spiegazione.
 
@@ -156,32 +155,32 @@ Il Listato 8-4 mostra un esempio di una classe personalizzata del modello, così
 Listato 8-4 - Esempio di file di una classe del modello, in `lib/model/doctrine/Article.php`
 
     [php]
-    class Articolo extends BaseArticolo
+    class Article extends BaseArticle
     {
     }
 
-La classe Articolo eredita ogni cosa della classe `BaseArticolo`, ma modifiche nello schema non hanno effetti su Articolo.
+La classe Articolo eredita ogni cosa della classe `BaseArticle`, ma modifiche nello schema non hanno effetti su Articolo.
 	
 Il meccanismo delle classi personalizzate che estendono delle classi base consente di iniziare lo sviluppo, anche senza conoscere il modello relazionale finale del database. La relativa struttura dei file rende il modello sia personalizzabile che estendibile.
 
 ### Classi di oggetti e tabelle
 
-`Articolo` e `Commento` sono classi di oggetti che rappresentano un record nel database. Forniscono accesso alle colonne di un record e ai relativi record. Questo significa che si è in grado di sapere il titolo di un articolo chiamando un metodo di un oggetto Articolo, come nell'esempio mostrato nel Listato 8-5.
+`Article` e `Comment` sono classi di oggetti che rappresentano un record nel database. Forniscono accesso alle colonne di un record e ai relativi record. Questo significa che si è in grado di sapere il titolo di un articolo chiamando un metodo di un oggetto Articolo, come nell'esempio mostrato nel Listato 8-5.
 
 Listato 8-5 - Nella classe dell'oggetto sono disponibili dei metodi getter per tutte le colonne del record
 
     [php]
-    $articolo = new Articolo();
+    $article = new Article();
     // ...
-    $titolo = $articolo->getTitolo();
+    $title = $article->getTitle();
 
-`ArticoloTable` e `CommentoTable` sono classi per le tabelle; cioè classi che contengono metodi pubblici che permettono di operare sulle tabelle. Essi forniscono un modo per recuperare i record dalle tabelle. I loro metodi di solito restituiscono un oggetto o un insieme di oggetti della relativa classe dell'oggetto, come mostrato nel Listato 8-6
+`ArticleTable` e `CommentTable` sono classi per le tabelle; cioè classi che contengono metodi pubblici che permettono di operare sulle tabelle. Essi forniscono un modo per recuperare i record dalle tabelle. I loro metodi di solito restituiscono un oggetto o un insieme di oggetti della relativa classe dell'oggetto, come mostrato nel Listato 8-6
 
 Listato 8-6 - Nella classe della tabella sono disponibili dei metodi pubblici per recuperare i record
 
     [php]
-    // $articolo è una istanza della classe Articolo
-    $articolo = Doctrine_Core::getTable('Articolo')->find(123);
+    // $article è una istanza della classe Article
+    $article = Doctrine_Core::getTable('Article')->find(123);
 
 Accesso ai dati
 ---------------
@@ -198,56 +197,56 @@ Campo, colonna| Proprietà
 
 ### Recuperare il valore della colonna
 
-Quando symfony costruisce il modello, crea una classe base di un oggetto per ciascuno dei modelli definiti nel file `schema.yml`. Ciascuna di queste classi è dotata di accessor e mutator predefiniti generati in base alle definizioni della colonna: i metodi `new`, `getXXX()` e `setXXX()` aiutano a creare oggetti e forniscono accesso alle proprietà dell'oggetto, come mostrato nel Listato 8-7.
+Quando symfony costruisce il modello, crea una classe base di un oggetto per ciascuno dei modelli definiti nel file `schema.yml`. Ciascuna di queste classi è dotata di accessori e modificatori predefiniti generati in base alle definizioni della colonna: i metodi `new`, `getXXX()` e `setXXX()` aiutano a creare oggetti e forniscono accesso alle proprietà dell'oggetto, come mostrato nel Listato 8-7.
 
 Listato 8-7 - Metodi generati nella classe dell'oggetto
 
     [php]
-    $articolo = new Articolo();
-    $articolo->setTitolo('Il mio primo articolo');
-    $articolo->setContenuto("Questo è il mio primo articolo.\n Spero che possa piacere!");
+    $article = new Article();
+    $article->setTitle('Il mio primo articolo');
+    $article->setContent("Questo è il mio primo articolo.\n Spero che possa piacere!");
 
-    $titolo   = $articolo->getTitolo();
-    $contenuto = $articolo->getContenuto();
+    $title   = $article->getTitle();
+    $content = $article->getContent();
 
 >**NOTE**
->La classe generata per l'oggetto è chiamata `Articolo` ma nel database il dato è memorizzato in una tabella chiamata `blog_articolo`. Se nello schema `tableName` non fosse stato definito, la classe sarebbe stata chiamata `articolo`. I metodi accessor e mutator usano una variante camelCase dei nomi delle colonne, quindi il metodo `getTitolo()` recupera il valore della colonna `titolo`.
+>La classe generata per l'oggetto è chiamata `Article` ma nel database il dato è memorizzato in una tabella chiamata `blog_articolo`. Se nello schema `tableName` non fosse stato definito, la classe sarebbe stata chiamata `article`. I metodi accessor e mutator usano una variante camelCase dei nomi delle colonne, quindi il metodo `getTitolo()` recupera il valore della colonna `titolo`.
 
 Per impostare molti campi in una sola volta, si può usare il metodo `fromArray()`, disponibile anche per ciascuna classe dell'oggetto, come mostrato nel Listato 8-8.
 
 Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
 
     [php]
-    $articolo->fromArray(array(
-      'Titolo'   => 'Il mio primo articolo',
-      'Contenuto' => 'Questo è il mio primo articolo.\n Spero che possa piacere!',
+    $article->fromArray(array(
+      'Title'   => 'Il mio primo articolo',
+      'Content' => 'Questo è il mio primo articolo.\n Spero che possa piacere!',
     ));
 
 ### Recuperare i record correlati
 
 La colonna `articolo_id` della tabella `blog_commento` definisce implicitamente una chiave esterna alla tabella `blog_articolo`. Ogni commento è correlato a un articolo e un articolo può avere molti commenti. Le classi generate contengono cinque metodi per tradurre queste relazioni in una modalità orientata agli oggetti. Sono i seguenti:
 
-  * `$commento->getArticolo()`: Per ottenere gli oggetti relativi ad `Articolo`
-  * `$commento->getArticoloId()`: Per ottenere l'ID del relativo oggetto `Articolo`
-  * `$commento->setArticolo($articolo)`: Per definire il relativo oggetto `Articolo`
-  * `$commento->setArticoloId($id)`: Per definire il relativo oggetto `Articolo` da un ID
-  * `$articolo->getCommenti()`: Per ottenere i relativi oggetti `Commento`
+  * `$comment->getArticle()`: Per ottenere gli oggetti relativi ad `Article`
+  * `$comment->getArticleId()`: Per ottenere l'ID del relativo oggetto `Article`
+  * `$comment->setArticolo($article)`: Per definire il relativo oggetto `Article`
+  * `$comment->setArticoloId($id)`: Per definire il relativo oggetto `Article` da un ID
+  * `$article->getCommenti()`: Per ottenere i relativi oggetti `Comment`
 
-I metodi `getArticoloId()` e `setArticoloId()` mostrano che si può considerare la colonna `articolo_id` come una normale colonna e impostare le relazioni a mano, ma non è una cosa molto utile. Il vantaggio di un approccio orientato agli oggetti è molto più evidente nei tre altri metodi. Il Listato 8-9 mostra come usare i metodi setter generati.
+I metodi `getArticleId()` e `setArticoloId()` mostrano che si può considerare la colonna `articolo_id` come una normale colonna e impostare le relazioni a mano, ma non è una cosa molto utile. Il vantaggio di un approccio orientato agli oggetti è molto più evidente nei tre altri metodi. Il Listato 8-9 mostra come usare i metodi setter generati.
 
 Listato 8-9 - Le chiavi esterne sono tradotte in un setter speciale
 
     [php]
-    $commento = new Commento();
-    $commento->setAutore('Fabrizio');
-    $commento->setContenuto('Fantastico, è il miglior articolo che ho letto!');
+    $comment = new Comment();
+    $comment->setAuthor('Fabrizio');
+    $comment->setContent('Fantastico, è il miglior articolo che ho letto!');
 
-    // Collega questo commento al precedente oggetto $articolo
-    $commento->setArticolo($articolo);
+    // Collega questo commento al precedente oggetto $article
+    $comment->setArticle($article);
 
     // Sintassi alternativa
     // Ha senso solo se l'oggetto è stato già salvato nel database
-    $commento->setArticoloId($articolo->getId());
+    $comment->setArticleId($article->getId());
 
 Il Listato 8-10 mostra come usare i metodi getter generati. Mostra anche come concatenare le chiamate di metodi sugli oggetti del modello.
 
@@ -255,27 +254,27 @@ Listato 8-10 - Le chiavi esterne sono tradotte in getter speciali
 
     [php]
     // Relazione molti a uno
-    echo $commento->getArticolo()->getTitolo();
+    echo $comment->getArticle()->getTitolo();
      => Il mio primo articolo
-    echo $commento->getArticolo()->getContenuto();
+    echo $comment->getArticle()->getContenuto();
      => Questo è il mio primo articolo.
 	    Spero che possa piacere!
 
     // Relazione uno a molti
-    $commenti = $articolo->getCommenti();
+    $commenti = $article->getComments();
 
-Il metodo `getArticolo()` restituisce un oggetto della classe `Articolo`, che trae beneficio dall'accessor `getTitolo()`. Questa è una operazione migliore rispetto a fare la join da soli, la quale può necessitare di qualche riga di codice in più (partendo dalla chiamata  `$commento->getArticoloId()`).
+Il metodo `getArticle()` restituisce un oggetto della classe `Article`, che trae beneficio dall'accessor `getTitolo()`. Questa è una operazione migliore rispetto a fare la join da soli, la quale può necessitare di qualche riga di codice in più (partendo dalla chiamata  `$comment->getArticleId()`).
 
-La variabile `$commenti` nel Listato 8-10 contiene un array di oggetti della classe `Commento`. Si può visualizzare il primo con `$commenti[0]` o iterare sulla collezione con `foreach ($commenti as $commento)`.
+La variabile `$commenti` nel Listato 8-10 contiene un array di oggetti della classe `Comment`. Si può visualizzare il primo con `$commenti[0]` o iterare sulla collezione con `foreach ($commenti as $comment)`.
 
 ### Salvare e cancellare i dati
 
 Chiamando il costruttore `new`, viene creato un nuovo oggetto, ma non un nuovo record nella tabella `blog_articolo`. La modifica dell'oggetto non ha effetto sul database. Per salvare i dati nel database, bisogna chiamare il metodo `save()` dell'oggetto.
 
     [php]
-    $articolo->save();
+    $article->save();
 
-L'ORM riesce a riconoscere le relazioni tra oggetti, quindi salvando l'oggetto `$articolo` viene anche salvato l'oggetto `$commento` a esso collegato. L'ORM sa anche se l'oggetto salvato ha una controparte esistente nel database , quindi la chiamata `save()` a volte è tradotta in SQL con `INSERT` e a volte con `UPDATE`. La chiave primaria è impostata automaticamente dal metodo `save()`, quindi dopo aver salvato, si può recuperare la nuova chiave primaria con `$articolo->getId()`.
+L'ORM riesce a riconoscere le relazioni tra oggetti, quindi salvando l'oggetto `$article` viene anche salvato l'oggetto `$comment` a esso collegato. L'ORM sa anche se l'oggetto salvato ha una controparte esistente nel database , quindi la chiamata `save()` a volte è tradotta in SQL con `INSERT` e a volte con `UPDATE`. La chiave primaria è impostata automaticamente dal metodo `save()`, quindi dopo aver salvato, si può recuperare la nuova chiave primaria con `$article->getId()`.
 
 >**TIP**
 >Si può controllare se un oggetto è nuovo, chiamando `isNew()`. Se si vuole sapere se un oggetto è stato modificato per eventualmente evitare il salvataggio, basta chiamare il metodo `isModified()`.
@@ -285,25 +284,25 @@ Se si leggono commenti ai propri articoli, si potrebbe cambiare idea circa l'opp
 Listato 8-11 - Cancellare i record dal database con il metodo `delete()` sul relativo oggetto
 
     [php]
-    foreach ($articolo->getCommenti() as $commento)
+    foreach ($article->getCommenti() as $comment)
     {
-      $commento->delete();
+      $comment->delete();
     }
 
 ### Recuperare i record tramite chiave primaria
 
-Se si conosce la chiave primaria di un certo record usare il metodo `find()` della classe della tabella per recuperare il relativo oggetto.
+Se si conosce la chiave primaria di un certo record, usare il metodo `find()` della classe della tabella per recuperare il relativo oggetto.
 
     [php]
-    $articolo = Doctrine_Core::getTable('Articolo')->find(7);
+    $article = Doctrine_Core::getTable('Article')->find(7);
 
-Il file `schema.yml` definisce il campo `id` come chiave primaria della tabella `blog_articolo`, quindi questo comando restituirà l'articolo che ha `id` 7. Essendo stata utilizzata la chiave primaria, sappiamo che verrà restituito solo un record; la variabile `$articolo` contiene un oggetto della classe `Articolo`.
+Il file `schema.yml` definisce il campo `id` come chiave primaria della tabella `blog_articolo`, quindi questo comando restituirà l'articolo che ha `id` 7. Essendo stata utilizzata la chiave primaria, sappiamo che verrà restituito solo un record; la variabile `$article` contiene un oggetto della classe `Article`.
 
-In alcuni casi, una chiave primaria piò essere costituita da più di una colonna. Per gestire questi casi, il metodo `find()` accetta parametri multipli, uno per ciascuna chiave primaria di colonna.
+In alcuni casi, una chiave primaria può essere costituita da più di una colonna. Per gestire questi casi, il metodo `find()` accetta parametri multipli, uno per ciascuna chiave primaria di colonna.
 
 ### Recuperare i record tramite Doctrine_Query
 
-Quando si vuole recuperare più di un record, bisogna chiamare il metodo `createQuery()` della classe della tabella corrispondente agli oggetti che si vogliono recuperare. Ad esempio, per recuperare oggetti della classe `Articolo`, chiamare `Doctrine_Core::getTable('Articolo')->createQuery()->execute()`.
+Quando si vuole recuperare più di un record, bisogna chiamare il metodo `createQuery()` della classe della tabella corrispondente agli oggetti che si vogliono recuperare. Ad esempio, per recuperare oggetti della classe `Article`, chiamare `Doctrine_Core::getTable('Article')->createQuery()->execute()`.
 
 Il primo parametro del metodo `execute()` è un array di parametri, che è l'array di valori per sostituire tutti i segnaposto trovati nella query.
 
@@ -312,7 +311,7 @@ Una `Doctrine_Query` vuota restituisce tutti gli oggetti della classe. Ad esempi
 Listato 8-12 - Recuperare i record di Doctrine_Query con `createQuery()`--Query vuota
 
     [php]
-    $q = Doctrine_Core::getTable('Articolo')->createQuery();
+    $q = Doctrine_Core::getTable('Article')->createQuery();
     $articoli = $q->execute();
 
     // Verrà generata la seguente query SQL
@@ -379,7 +378,7 @@ Infine, se si vuole che venga restituito solo il primo oggetto, sostituire la ch
 >**TIP**
 >Quando una query `execute()` restituisce un grosso numero di risultati, si potrebbe voler visualizzare solo un sottoinsieme di questi nella risposta. Symfony fornisce una classe per la paginazione chiamata `sfDoctrinePager`, che automatizza la paginazione dei risultati.
 
-### Utilizzo di query SQL raw
+### Utilizzo di query in puro SQL
 
 A volte non si vogliono recuperare oggetti, ma solo risultati sintetici calcolati dal database. Ad esempio, per ottenere l'ultima data di creazione tra tutti gli articoli, non ha senso recuperare tutti gli articoli e ciclare sull'array. Si preferirà chiedere al database di restituire solo il risultato, perché in questo modo verrà saltato il processo di idratazione.
 
@@ -418,12 +417,12 @@ La buona notizia è che Doctrine ha un comportamento `Timestampable` che gestir
 Listato 8-16 - Le colonne `created_at` e `updated_at` Columns sono gestite automaticamente
 
     [php]
-    $commento = new Commento();
-    $commento->setAutore('Fabrizio');
-    $commento->save();
+    $comment = new Commento();
+    $comment->setAutore('Fabrizio');
+    $comment->save();
 
     // Mostra la creazione della data
-    echo $commento->getCreatedAt();
+    echo $comment->getCreatedAt();
       => [data dell'operazione di INSERT nel database]
 
 >**SIDEBAR**
@@ -441,12 +440,12 @@ Listato 8-16 - Le colonne `created_at` e `updated_at` Columns sono gestite autom
 >       $this->articoli = $tag->getArticoliPopolari(10);
 >     }
 >
->L'azione crea un oggetto  della classe `Tag` dal parametro della request. Tutto il codice necessario per interrogare il database si trova nel metodo `getArticoliPopolari` di questa classe. Rende l'azione più leggibile e il codice del modello può facilmente venire riutilizzato in un'altra azione.
+>L'azione crea un oggetto  della classe `Tag` dal parametro della richiesta. Tutto il codice necessario per interrogare il database si trova nel metodo `getArticoliPopolari` di questa classe. Rende l'azione più leggibile e il codice del modello può facilmente venire riutilizzato in un'altra azione.
 >
 >Spostare il codice in un posto più appropriato è una delle tecniche della rifattorizzazione. Se la si fa spesso, il codice sarà semplice da mantenere e da comprendere da parte di altri sviluppatori. Una buona regola per capire quando fare refactoring nel livello dei dati, è che il codice di una azione raramente deve contenere più di dieci righe di codice PHP.
 
 Connessioni al database
----------------------------
+------------------------
 
 Il modello del dati è indipendente dal database usato, ma dovrà sicuramente utilizzare un database. Le minime informazioni richieste da symfony per inviare richieste al database del progetto sono il nome, le credenziali e il tipo di database. Queste impostazioni per la connessione possono essere configurate passando il nome della sorgente dati (DSN, data source name) al task `configure:database`:
 
@@ -514,7 +513,7 @@ I metodi generati del modello sono utili ma a volte non sufficienti. Non appena
 
 Si possono aggiungere nuovi metodi alle classi vuote del modello generate nella cartella `lib/model/doctrine`. Usare `$this` per chiamare i metodi dell'oggetto corrente e usare `self::` per chiamare metodi statici della classe corrente. Ricordarsi che le classi personalizzate ereditano i metodi dalle classi `Base` presenti nella cartella `lib/model/doctrine/base`.
 
-Ad esempio, per l'oggetto `Articolo` generato basandosi sul Listato 8-3, si può aggiungere un metodo magico `__toString()` in modo che faccendo l'echo di un oggetto della classe `Articolo` venga visualizzato il suo titolo, come mostrato nel Listato 8-20.
+Ad esempio, per l'oggetto `Article` generato basandosi sul Listato 8-3, si può aggiungere un metodo magico `__toString()` in modo che faccendo l'echo di un oggetto della classe `Article` venga visualizzato il suo titolo, come mostrato nel Listato 8-20.
 
 Listato 8-20 - Personalizzazione del modello, in `lib/model/doctrine/Articolo.php`
 
@@ -548,17 +547,17 @@ I nuovi metodi sono disponibili nello stesso modo di quelli generati, come mostr
 Listato 8-22 - Usare i metodi personalizzati dei modelli è come usare i metodi generati
 
     [php]
-    $articoli = Doctrine_Core::getTable('Articolo')->getTuttoOrdinatoPerData();
-    foreach ($articoli as $articolo)
+    $articoli = Doctrine_Core::getTable('Article')->getTuttoOrdinatoPerData();
+    foreach ($articoli as $article)
     {
-      echo $articolo;      // Chiamerà il metodo magico __toString()
+      echo $article;      // Chiamerà il metodo magico __toString()
     }
 
 ### Sovrascrivere i metodi esistenti
 
 Se alcuni dei metodi generati nelle classi `Base` non si adattano alle proprie esigenze, si può sovrascriverle nella classe personalizzata. Basta fare in modo di utilizzare la stessa firma nel metodo (cioè lo stesso numero di argomenti).
 
-Ad esempio, il metodo `$article->getCommenti()` restituisce una collezione di oggetti `Commento`, in nessun ordine particolare. Se si vogliono avere i risultati ordinati per data di creazione, con gli ultimi commenti messi all'inizio, allora bisogna creare il metodo `getCommenti()` come mostrato nel Listato 8-23.
+Ad esempio, il metodo `$article->getCommenti()` restituisce una collezione di oggetti `Comment`, in nessun ordine particolare. Se si vogliono avere i risultati ordinati per data di creazione, con gli ultimi commenti messi all'inizio, allora bisogna creare il metodo `getCommenti()` come mostrato nel Listato 8-23.
 
 Listato 8-23 - Sovrascrivere i metodi esistenti del modello, in `lib/model/Articolo.php`
 
@@ -594,7 +593,7 @@ Per abilitare i comportamenti nelle classi del modello, è necessario modificare
         titolo:   string(255)
         contenuto: clob
 
-Dopo aver rigenerato i modelli, il modello `Articolo` ha una colonna slug che è automaticamente impostata con una stringa "amichevole" per le url basata sul titolo.
+Dopo aver rigenerato i modelli, il modello `Article` ha una colonna slug che è automaticamente impostata con una stringa "amichevole" per le url basata sul titolo.
 		
 Alcuni dei comportamenti disponibili per Doctrine sono:
 
@@ -625,7 +624,7 @@ Listato 8-24 - Attributi per le impostazioni del modello
 
 L'attributo `export` controlla quale SQL è esportato al database quando vengono create le tabelle per questo modello. Utilizzando il valore `tables` viene solo esportata la struttura della tabella e non le chiavi esterne, gli indici, ecc.
 
-Le tabelle che contengono contenuto localizzato (cioè, diverse versioni del contenuto, in una tabella correlata per l'internazionalizzazione) devono utilizzare il comportamento I18n (si veda il Capitolo 13 per dettagli), come mostrato nel Listato 8-25.
+Le tabelle che contengono contenuto localizzato (cioè, diverse versioni del contenuto, in una tabella correlata per l'internazionalizzazione) devono utilizzare il comportamento I18n (si veda il capitolo 13 per dettagli), come mostrato nel Listato 8-25.
 
 Listato 8-25 - Il comportamento I18n
 
@@ -636,7 +635,7 @@ Listato 8-25 - Il comportamento I18n
           fields: [titolo, contenuto]
 
 >**SIDEBAR**
->Trattare con più schemi
+>Gestire schemi multipli
 >
 >Si può avere più di uno schema per applicazione. Symfony considererà tutti i file che finiscono con`.yml` presenti nella cartella `config/doctrine`. Se l'applicazione ha molti modelli, o se alcuni modelli non condividono la stessa connessione, si potrà trovare questo approccio molto utile.
 >
@@ -662,7 +661,7 @@ Listato 8-25 - Il comportamento I18n
 >         resource: string(100)
 >
 >
->Entrambi gli schemi condividono la stessa connessione (`doctrine`) e le classi `Articolo` e `Hit` verranno generate sotto la stessa cartella `lib/model/doctrine`. Tutto avviene come se si fosse scritto un solo schema.
+>Entrambi gli schemi condividono la stessa connessione (`doctrine`) e le classi `Article` e `Hit` verranno generate sotto la stessa cartella `lib/model/doctrine`. Tutto avviene come se si fosse scritto un solo schema.
 >
 >Si possono anche avere schemi diversi che usano connessioni diverse (ad esempio, `doctrine` e `doctrine_bis`, da definire `databases.yml`) e associarli a questa connessione:
 >
@@ -689,7 +688,7 @@ Listato 8-25 - Il comportamento I18n
 >         resource: string(100)
 >
 >
->Molte applicazioni usano più di uno schema. In particolare, alcuni plug-in hanno il loro proprio schema per evitare problemi con quelli di altre classi (vedere il capitolo 17 per maggiori dettagli).
+>Molte applicazioni usano più di uno schema. In particolare, alcuni plugin hanno il proprio schema, per evitare problemi con quelli di altre classi (vedere il capitolo 17 per maggiori dettagli).
 
 ### Dettagli delle colonne
 
@@ -748,11 +747,11 @@ Listato 8-28 - Sintassi alternativa per la chiave esterna
           onDelete: CASCADE
           foreignAlias: Articles
 
-### Indexes
+### Indici
 
-Si possono aggiungere indici in un modello, sotto la chiave `indexes:`. Se si vogliono definire indici univoci, bisogna usare la sintassi `type: unique`. Per le colonne che richiedono una dimensione, perché sono colonne di testo, la dimensione dell'indice è specificata nello stesso modo della lunghezza della colonna usando le parentesi. Il Listato 8-30 mostra la sintassi alternativa per gli indici.
+Si possono aggiungere indici in un modello, sotto la chiave `indexes:`. Se si vogliono definire chiavi univoche, bisogna usare la sintassi `type: unique`. Per le colonne che richiedono una dimensione, perché sono colonne di testo, la dimensione dell'indice è specificata nello stesso modo della lunghezza della colonna, usando le parentesi. Il Listato 8-30 mostra la sintassi alternativa per gli indici.
 
-Listato 8-30 - Indici e indici univoci
+Listato 8-30 - Indici e chiavi univoche
 
     [yml]
     Articolo:
@@ -785,7 +784,7 @@ Listato 8-30 - Indici e indici univoci
 
 Symfony supporta l'internazionalizzazione dei contenuti tramite tabelle dedicate. Questo significa che quando si ha un contenuto da internazionalizzare, viene memorizzato in due tabelle separate: una per le colonne che non cambiano e una per le colonne da internazionalizzare.
 
-Listato 8-33 - Meccanismo I18n
+Listato 8-33 - Meccanismo i18n
 
     [yml]
     DbGroup:
@@ -797,7 +796,7 @@ Listato 8-33 - Meccanismo I18n
 
 ### Comportamenti
 
-I comportamenti sono modificatori dei modelli forniti da plug-in, che aggiungono nuove capacità alle classi di Doctrine. Il capitolo 17 parla più approfonditamente dei comportamenti. I comportamenti si possono definire nello schema, elencandoli per ciascuna tabella, insieme con i loro parametri, sotto la chiave `actAs`. Il Listato 8-34 fornisce un esempio estendendo la classe `Articolo` con il comportamento `Sluggable`.
+I comportamenti sono modificatori dei modelli forniti da plugin, che aggiungono nuove capacità alle classi di Doctrine. Il capitolo 17 parla più approfonditamente dei comportamenti. I comportamenti si possono definire nello schema, elencandoli per ciascuna tabella, insieme con i loro parametri, sotto la chiave `actAs`. Il Listato 8-34 fornisce un esempio estendendo la classe `Article` con il comportamento `Sluggable`.
 
 Listato 8-34 - Dichiarazione dei comportamenti
 
@@ -809,7 +808,7 @@ Listato 8-34 - Dichiarazione dei comportamenti
 Non creare il modello due volte
 -------------------------------
 
-Lo svantaggio nell'utilizzo di un ORM è che bisogna definire la struttura dati due volte: una per il database e una per il modello a oggetti. Per fortuna, symfony fornisce dei tool a riga di comando per generare l'uno basato sull'altro, in modo da evitare la duplicazione del lavoro.
+Lo svantaggio nell'utilizzo di un ORM è che bisogna definire la struttura dati due volte: una per il database e una per il modello a oggetti. Per fortuna, symfony fornisce degli strumenti a riga di comando per generare l'uno basato sull'altro, in modo da evitare la duplicazione del lavoro.
 
 ### Creare l'SQL della struttura di un database basandosi su uno schema esistente
 
@@ -824,7 +823,7 @@ Si può usare il file `schema.sql` direttamente per costruire le tabelle. Ad ese
     $ mysqladmin -u root -p create blog
     $ mysql -u root -p blog < data/sql/schema.sql
 
-L'SQL generato è utile anche per ricostruire il database in un altro ambiente o per passare a un altro DBMS.
+Il codice SQL generato è utile anche per ricostruire il database in un altro ambiente o per passare a un altro DBMS.
 
 >**TIP**
 >La riga di comando offre anche un task per popolare il database con i dati caricati da un file di testo. Vedere il capitolo 16 per maggiori informazioni sul task `doctrine:data-load` e i file delle fixture in YAML.
@@ -842,7 +841,7 @@ Dalla struttura del database viene generato un nuovo file `schema.yml` nella car
 Riepilogo
 ---------
 
-Symfony usa Doctrine come ORM e PHP Data Objects per il livello di astrazione del database. Ciò significa che è necessario prima descrivere lo schema relazionale del database in YAML prima di generare le classi del modello a oggetti. Poi, in fase di runtime, utilizzare i metodi dell'oggetto e le classi delle tabelle per recuperare informazioni su un record o un insieme di record. È possibile facilmente sovrascrivere ed estendere il modello aggiungendo metodi alle classi personalizzate. Le impostazioni di connessione sono definite in un file `databases.yml`, che può supportare più di una connessione. E la linea di comando contiene dei task speciali per evitare di duplicare la definizione della struttura. 
+Symfony usa Doctrine come ORM e gli oggetti dei dati di PHP per il livello di astrazione del database. Ciò significa che è necessario prima descrivere lo schema relazionale del database in YAML prima di generare le classi del modello a oggetti. Poi, in fase di runtime, utilizzare i metodi dell'oggetto e le classi delle tabelle per recuperare informazioni su un record o un insieme di record. È possibile sovrascrivere ed estendere facilmente il modello aggiungendo metodi alle classi personalizzate. Le impostazioni di connessione sono definite in un file `databases.yml`, che può supportare più di una connessione. E la linea di comando contiene dei task speciali per evitare di duplicare la definizione della struttura. 
 
 Il livello del modello è il più complesso del framework symfony. Una delle ragioni di questa complessità è che la manipolazione dei dati è una questione intricata. I problemi di sicurezza correlati sono fondamentali per un sito web e non devono essere ignorati. Un'altra ragione è che symfony è più adatto ad applicazioni di medio-grandi dimensioni in contesto enterprise. In tali applicazioni, le automazioni fornite dal modello di symfony possono davvero rappresentare un guadagno di tempo che vale l'investimento per apprendere il suo funzionamento. 
 
diff --git a/gentle-introduction/it/10-Forms.markdown b/gentle-introduction/it/10-Forms.markdown
index 27bb916..f70e493 100644
--- a/gentle-introduction/it/10-Forms.markdown
+++ b/gentle-introduction/it/10-Forms.markdown
@@ -1,5 +1,5 @@
-Chapter 10 - I form
-===================
+Capitolo 10 - I form
+====================
 
 La visualizzazione degli input di un form, la validazione dei dati inseriti in un form e tutta la casistica particolare del trattamento dei form è uno dei compiti più complessi nello sviluppo web. Fortunatamente, symfony fornisce un'interfaccia semplice verso un potente sottosistema dedicato ai form, e facilita la creazione e la manipolazione con poche linee di codice di form di qualsiasi livello di complessità.
 
@@ -415,7 +415,7 @@ I widget data sono un buon esempio della potenza dei widget in symfony. Un widge
 
 ### I widget I18n
 
-Nelle applicazioni multilingua, le date devono essere mostrare in un formato che si accordi con la cultura dell'utente (si veda il Capitolo 13 per dettagli riguardo cultura e localizzazione). Per facilitare questa localizzazione nei form, symfony offre un widget `sfWidgetFormI18nDate`, che si basa sulla `culture` dell'utente per stabilire i parametri di formattazione delle date. È anche possibile specificare un `month_format` per visualizzare una lista drop-down con i nomi dei mesi (nella lingua dell'utente) invece dei numeri.
+Nelle applicazioni multilingua, le date devono essere mostrare in un formato che si accordi con la cultura dell'utente (si veda il capitolo 13 per dettagli riguardo cultura e localizzazione). Per facilitare questa localizzazione nei form, symfony offre un widget `sfWidgetFormI18nDate`, che si basa sulla `culture` dell'utente per stabilire i parametri di formattazione delle date. È anche possibile specificare un `month_format` per visualizzare una lista drop-down con i nomi dei mesi (nella lingua dell'utente) invece dei numeri.
 
     [php]
     // Data
@@ -741,7 +741,7 @@ Ogni validatore invalido risulta in un messaggio di errore nel campo. Questi mes
       ))
     ));
 
-Naturalmente, questi messaggi personalizzati vengono resi nei template attraverso gli helper i18n, così le applicazioni multilingua possono anche tradurre i messaggi di errore personalizzati in un dizionario (si veda il Capitolo 13 per ulteriori dettagli).
+Naturalmente, questi messaggi personalizzati vengono resi nei template attraverso gli helper i18n, così le applicazioni multilingua possono anche tradurre i messaggi di errore personalizzati in un dizionario (si veda il capitolo 13 per ulteriori dettagli).
 
 ### Applicare un validatore a più campi
 
diff --git a/gentle-introduction/it/13-I18n-and-L10n.markdown b/gentle-introduction/it/13-I18n-and-L10n.markdown
index 8bad08a..98e0333 100644
--- a/gentle-introduction/it/13-I18n-and-L10n.markdown
+++ b/gentle-introduction/it/13-I18n-and-L10n.markdown
@@ -485,7 +485,7 @@ nella stessa cartella.
 >corretta di una data stringa potrebbe richiedere un po' di tempo, symfony usa una cache
 >interna per accelerare il processo. Per impostazione predefinita, questa cache usa il
 >filesystem. Si può configurare la modalità di funzionamento della cache i18n (ad esempio,
->per condividere la cache tra server diversi) in `factories.yml` (vedere Capitolo 19).
+>per condividere la cache tra server diversi) in `factories.yml` (vedere capitolo 19).
 
 ### Gestire i dizionari
 
@@ -509,7 +509,7 @@ Un altro modo per organizzare i dizionari è quello di dividerli per modulo. Inv
 scrivere un singolo file `messages.XX.xml` per l'intera applicazione, se ne può scrivere
 uno in ogni cartella `modules/[nome_modulo]/i18n/`. Questo rende i moduli più
 indipendenti dall'applicazione, il che è necessario se si vuole riutilizzarli, come in
-un plugin (vedere Capitolo 17).
+un plugin (vedere capitolo 17).
 
 Poiché l'aggiornamento manuale dei dizionari è spesso soggetto a errori, symfony fornisce
 un task per automatizzare il processo. Il task `i18n:extract` analizza un'applicazione
@@ -552,7 +552,7 @@ I seguenti sono altri elementi che potrebbero richiedere traduzione:
   * Le pagine predefinite di symfony (pagina non trovata, errore interno del server,
     accesso vietato, ecc.) sono in inglese e devono essere riscritte in una applicazione
     i18n. Probabilmente si vorrà creare un proprio modulo `default` nell'applicazione e
-    usare `__()` nei suoi template. Si faccia riferimento al Capitolo 19 per vedere come
+    usare `__()` nei suoi template. Si faccia riferimento al capitolo 19 per vedere come
     personalizzare queste pagine.
 
 ### Gestire esigenze complesse di traduzione
diff --git a/gentle-introduction/it/16-Application-Management-Tools.markdown b/gentle-introduction/it/16-Application-Management-Tools.markdown
index 8abbea2..ae429cf 100644
--- a/gentle-introduction/it/16-Application-Management-Tools.markdown
+++ b/gentle-introduction/it/16-Application-Management-Tools.markdown
@@ -357,7 +357,7 @@ Listato 16-12 - Esempio di script batch, in `lib/mioScript.php`
 
     // aggiungere qua il codice
 
-Assomiglia molto alle prime righe di un front controller (vedere il Capitolo 6), perché queste linee fanno la stessa cosa: inizializzano symfony, analizzano la configurazione del progetto e dell'applicazione. Notare che il metodo `ProjectConfiguration::getApplicationConfiguration` richiede tre parametri:
+Assomiglia molto alle prime righe di un front controller (vedere il capitolo 6), perché queste linee fanno la stessa cosa: inizializzano symfony, analizzano la configurazione del progetto e dell'applicazione. Notare che il metodo `ProjectConfiguration::getApplicationConfiguration` richiede tre parametri:
 
  * un nome di applicazione
  * un nome di ambiente
@@ -501,7 +501,7 @@ Nella chiamata è possibile specificare un'altra cartella per le fixture. In que
 
 Si è imparato come aggiungere record a una singola tabella, ma come si fa ad aggiungere record con chiavi esterne a un'altra tabella? Dal momento che la chiave primaria non è inclusa nei dati delle fixture, c'è bisogno di un modo alternativo per relazionare dei record con altri.
 
-Torniamo all'esempio del Capitolo 8, dove la tabella `blog_article` è collegata alla tabella `blog_comment`, come mostrato in Figura 16-8.
+Torniamo all'esempio del capitolo 8, dove la tabella `blog_article` è collegata alla tabella `blog_comment`, come mostrato in Figura 16-8.
 
 Figura 16-8 - Esempio di un modello relazionale di database
 
@@ -551,7 +551,7 @@ Symfony offre comandi manuali per sincronizzare due versioni di un sito web. Que
 
 ### L'utilizzo di `rsync` per il trasferimento incrementale di file
 
-L'invio della cartella principale di un progetto tramite FTP va bene per il primo trasferimento, ma quando si ha bisogno di caricare un aggiornamento dell'applicazione, in cui sono cambiati solo alcuni file, l'FTP non è l'ideale. È necessario trasferire nuovamente l'intero progetto, il che è uno spreco di tempo e di larghezza di banda. In alternativa si può passare alla directory in cui si sa che alcuni file sono stati modificati e trasferire solo quelli con certe date di modifica. Questo è un lavoro che richiede tempo ed è suscettibile di errori. Inoltre, il sito web può diventare non disponibile o restituire errori durante il tempo del trasferimento. 
+L'invio della cartella principale di un progetto tramite FTP va bene per il primo trasferimento, ma quando si ha bisogno di caricare un aggiornamento dell'applicazione, in cui sono cambiati solo alcuni file, l'FTP non è l'ideale. È necessario trasferire nuovamente l'intero progetto, il che è uno spreco di tempo e di larghezza di banda. In alternativa si può passare alla cartella in cui si sa che alcuni file sono stati modificati e trasferire solo quelli con certe date di modifica. Questo è un lavoro che richiede tempo ed è suscettibile di errori. Inoltre, il sito web può diventare non disponibile o restituire errori durante il tempo del trasferimento. 
 
 La soluzione supportata da symfony è la sincronizzazione rsync attraverso SSH. [Rsync] (http://samba.anu.edu.au/rsync/) è una utility a riga di comando che consente il trasferimento incrementale di file in modo veloce ed è open source. Con il trasferimento incrementale, solo i dati modificati verranno inviati. Se un file non è stato modificato, non sarà inviato all'host. Se un file è stato modificato solo in parte, sarà inviata solo la parte cambiata. Il vantaggio principale è che la sincronizzazione con rsync trasferire solo una piccola quantità di dati ed è molto veloce.
 
@@ -598,11 +598,11 @@ Non dimenticarsi di cancellare la cache nel server di produzione dopo la sincron
 >
 >Prima di inviare l'applicazione in produzione, bisogna essere sicuri che sia pronta per un utilizzo pubblico. Verificare i punti seguenti prima di decidere di distribuire l'aplicazione:
 >
->Le pagine degli errori devono essere personalizzate in base al look and feel dell'applicazione. Fare riferimento al Capitolo 19 per vedere come personalizzare l'errore 500, l'errore 404, le pagine messe in sicurezza e alla sezione "Gestire un'applicazione in produzione" di questo capitolo per vedere come personalizzare le pagine visualizzate quando il sito non è disponibile.
+>Le pagine degli errori devono essere personalizzate in base al look and feel dell'applicazione. Fare riferimento al capitolo 19 per vedere come personalizzare l'errore 500, l'errore 404, le pagine messe in sicurezza e alla sezione "Gestire un'applicazione in produzione" di questo capitolo per vedere come personalizzare le pagine visualizzate quando il sito non è disponibile.
 >
 >Il modulo `default` dovrebbe essere rimosso dall'array `enabled_modules` presente in `settings.yml`, in modo che nessuna pagina di symfony possa comparire per errore.
 >
->Il meccanismo di gestione della sessione utilizza un cookie lato client e questo cookie in modalità predefinita si chiama `symfony`. Prima di distribuire l'applicazione, si dovrebbe rinominarlo, in modo da evitare la divulgazione del fatto che l'applicazione utilizza symfony. Fare riferimento al Capitolo 6 per vedere come personalizzare il nome del cookie nel file `factories.yml`.
+>Il meccanismo di gestione della sessione utilizza un cookie lato client e questo cookie in modalità predefinita si chiama `symfony`. Prima di distribuire l'applicazione, si dovrebbe rinominarlo, in modo da evitare la divulgazione del fatto che l'applicazione utilizza symfony. Fare riferimento al capitolo 6 per vedere come personalizzare il nome del cookie nel file `factories.yml`.
 >
 > Il file `robots.txt` che si trova nella cartella `web/` del progetto, in modalità predefinita è vuoto. Si consiglia di personalizzarlo per informare spider web e robot web su quali parti del sito web possono navigare e quali dovrebbero ignorare. Il più delle volte, questo file viene utilizzato per escludere alcune URL dall'indicizzazione; per esempio le pagine di risorse che non hanno bisogno di indicizzazione (come l'archivio dei bug), o gli infiniti URL in cui i robot potrebbero rimanere bloccati. 
 >
diff --git a/gentle-introduction/it/17-Extending-Symfony.markdown b/gentle-introduction/it/17-Extending-Symfony.markdown
index acad501..ae98d32 100644
--- a/gentle-introduction/it/17-Extending-Symfony.markdown
+++ b/gentle-introduction/it/17-Extending-Symfony.markdown
@@ -86,7 +86,7 @@ Il metodo `notify()` del dispatcher di eventi si aspetta un oggetto `sfEvent` co
 
 ### Notifica di un evento al dispatcher finché un ascoltatore lo prende in carico
 
-Usando il metodo `notify()`, si è sicuri che tutti gli ascoltatori registrati sull'evento da notificare vengono eseguiti. Tuttavia, in alcuni casi è necessario consentire a un ascoltatore di fermare l'evento e prevenire che ulteriori ascoltatori possano fare notifiche su di esso. In questo caso, si dovrebbe usare `notifyUntil()` al posto di `notify()`. Il dispatcher eseguirà tutti gli ascoltatori fino a quando uno di questi ritorna `true` e quindi fermerà la notifica degli eventi. In altre parole, `notifyUntil()` è come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Se qualcuno se ne occupa, allora non lo dirò a nessun altro". Il Listato 17-3 mostra come usare questa tecnica in combinazione con un metodo magico `__call()` per aggiungere metodi a una classe esistente in fase di runtime.
+Usando il metodo `notify()`, si è sicuri che tutti gli ascoltatori registrati sull'evento da notificare vengono eseguiti. Tuttavia, in alcuni casi è necessario consentire a un ascoltatore di fermare l'evento e prevenire che ulteriori ascoltatori possano fare notifiche su di esso. In questo caso, si dovrebbe usare `notifyUntil()` al posto di `notify()`. Il dispatcher eseguirà tutti gli ascoltatori fino a quando uno di questi restituisce `true` e quindi fermerà la notifica degli eventi. In altre parole, `notifyUntil()` è come un messaggio nello spazio del progetto che dice: "Sto facendo questo. Se qualcuno se ne occupa, allora non lo dirò a nessun altro". Il Listato 17-3 mostra come usare questa tecnica in combinazione con un metodo magico `__call()` per aggiungere metodi a una classe esistente in fase di runtime.
 
 Listato 17-3 - Notifica di un evento finché l'ascoltatore restituisce true
 
diff --git a/gentle-introduction/it/19-Mastering-Symfony-s-Configuration-Files.markdown b/gentle-introduction/it/19-Mastering-Symfony-s-Configuration-Files.markdown
index 2f3cce1..0c98e0f 100644
--- a/gentle-introduction/it/19-Mastering-Symfony-s-Configuration-Files.markdown
+++ b/gentle-introduction/it/19-Mastering-Symfony-s-Configuration-Files.markdown
@@ -36,7 +36,7 @@ definisce quale azione eseguire, a seconda dell'errore:
     Il valore predefinito è `default/error404`.
   * `login_module` e `login_action`: Azione richiamata quando un utente non autenticato
     tenta di accedere a una pagina definita come `secure` in `security.yml` (si veda il
-    Capitolo 6 per maggiori dettagli). Il valore predefinito è `default/login`.
+    capitolo 6 per maggiori dettagli). Il valore predefinito è `default/login`.
   * `secure_module` e `secure_action`: Azione richiamata quando un utente non ha le
     credenziali necessarie per un'azione. Il valore predefinito è `default/secure`.
   * `module_disabled_module` e `module_disabled_action`: Azione richiamata quando un
@@ -69,7 +69,7 @@ possono trovare queste pagine nella cartella
   * `error.html.php`: Pagina richiamata quando si verifica un errore interno del server in
     ambiente di produzione. In altri ambienti (quando debug è impostato a `true`), in caso
     di errore, symfony mostra l'intera pila di esecuzione con un messaggio di errore
-    esplicito (si veda il Capitolo 16 per maggiori dettagli).
+    esplicito (si veda il capitolo 16 per maggiori dettagli).
   * `unavailable.php`: Pagina richiamata quando un utente richiede una pagina mentre
      l'applicazione è disabilitata (tramite il task `project:disable`). Viene anche
      richiamata quando la cache è in fase di pulizia (cioè tra la chiamata al task
@@ -101,11 +101,11 @@ Tabella 19-1 - Caratteristiche opzionali configurabili in `settings.yml`
 Parametro           | Descrizione                                    | Valore predefinito
 ------------------- | ---------------------------------------------- | ------------------
 `use_database`      | Abilita la gestione del database. Impostare a `false` se non si usa un database. | `true`
-`i18n`              | Abilita la traduzione dell'interfaccia (si veda il Capitolo 13). Impostare a `true` per applicazioni multi-lingua. | `false`
+`i18n`              | Abilita la traduzione dell'interfaccia (si veda il capitolo 13). Impostare a `true` per applicazioni multi-lingua. | `false`
 `logging_enabled`   | Abilita il log degli eventi di symfony. Impostare a `false` se si vogliono disabilitare i log. | `true`
-`escaping_strategy` | Abilita l'escape dell'output (si veda il Capitolo 7). Impostare a `true` se si vuole l'escape dei dati passati ai template. | `true`
-`cache`             | Abilita template caching (see Capitolo 12). Impostare a `true` se almeno un modulo include il file `cache.yml`. Il filtro della cache (`sfCacheFilter`) è abilitato. | `false` in sviluppo, `true` in produzione
-`web_debug`         | Abilita la web debug toolbar per facilitare il debug (si veda il Capitolo 16). Impostare a `true` per mostrare toolbar su ogni pagina. | `true` in sviluppo, `false` in produzione
+`escaping_strategy` | Abilita l'escape dell'output (si veda il capitolo 7). Impostare a `true` se si vuole l'escape dei dati passati ai template. | `true`
+`cache`             | Abilita template caching (see capitolo 12). Impostare a `true` se almeno un modulo include il file `cache.yml`. Il filtro della cache (`sfCacheFilter`) è abilitato. | `false` in sviluppo, `true` in produzione
+`web_debug`         | Abilita la web debug toolbar per facilitare il debug (si veda il capitolo 16). Impostare a `true` per mostrare toolbar su ogni pagina. | `true` in sviluppo, `false` in produzione
 `check_symfony_version` | Abilita la verifica della versione di symfony a ogni richiesta. Impostare a `true` per pulire la cache automaticamente dopo un aggiornamento di symfony. Lasciare a `false` se si pulisce la cache a mano dopo un aggiornamento. | `false`
 `check_lock`        | Abilita il sistema di blocco dell'applicazione, attivato dai task `cache:clear` e `project:disable` (vedere la sezione precedente). Impostare a `true` per fare in modo che tutte le richieste ad applicazioni disabilitate siano rinviate alla pagina `sfConfig::get('sf_symfony_lib_dir')/exception/data/unavailable.php`. | `false`
 `compressed`        | Abilita la compressione della risposta in PHP. Impostare a `true` per comprimere il codice HTML in uscita tramite il gestore di compressione di PHP. | `false`
@@ -119,7 +119,7 @@ parti.
 #### Impostazioni dell'escape dell'output
 
 Le impostazioni di escape dell'output controllano il modo in cui il template accede alle
-variabili (vedere Capitolo 7). Il file `settings.yml` include due impostazioni per questa
+variabili (vedere capitolo 7). Il file `settings.yml` include due impostazioni per questa
 caratteristica:
 
   * L'impostazione `escaping_strategy` accetta i valori `true` o `false`.
@@ -128,7 +128,7 @@ caratteristica:
 
 #### Impostazioni del routing
 
-Le impostazioni del routing (vedere Capitolo 9) sono definite in `factories.yml`, sotto
+Le impostazioni del routing (vedere capitolo 9) sono definite in `factories.yml`, sotto
 la chiave `routing`. Il Listato 19-1 mostra la configurazione predefinita del routing.
 
 Listato 19-1 - Impostazioni di configurazione del routing, in `frontend/config/factories.yml`
@@ -172,7 +172,7 @@ Listato 19-1 - Impostazioni di configurazione del routing, in `frontend/config/f
   * Lo schema del routing usa una sua cache, in produzione, per accelerare la conversione
     tra URL esterni e interni. Per impostazione predefinita, questa cache usa il
     filesystem, ma si può usare qualsiasi classe di cache, a patto di dichiarare tale
-    classe e le sue impostazioni nel parametro `cache`. Vedere il Capitolo 15 per la lista
+    classe e le sue impostazioni nel parametro `cache`. Vedere il capitolo 15 per la lista
     delle classi disponibili. Per disattivare la cache del routing in produzione,
     impostare il parametro `debug` a `true`.
 
@@ -198,7 +198,7 @@ Ci sono altri parametri legati al routing, ma questo si trova in `settings.yml`:
 >funzionano solo abilitando il plugin `sfCompat10`.
 
 Le impostazioni di validazione dei form controllano il modo in cui i messaggi di errore
-sono mostrati dagli helper `Validation` (vedere Capitolo 10). Questi errori sono inseriti
+sono mostrati dagli helper `Validation` (vedere capitolo 10). Questi errori sono inseriti
 in tag `<div>` usano `validation_error_ class` come attributo `class` e
 `validation_error_id_prefix` per costruire l'attributo `id`. I valori predefiniti sono
 `form_error` e `error_for_`, quindi gli attributi mostrati da una chiamata all'helper
@@ -212,7 +212,7 @@ per personalizzare tutti i messaggi di errore.
 
 Le impostazioni della cache sono definiti per la maggior parte in `cache.yml`, tranne per
 due impostazioni in `settings.yml`: `cache` abilita la cache e `etag` abilita la gestione
-di ETag sul server (vedere Capitolo 15). Si può anche specificare quale sistema di
+di ETag sul server (vedere capitolo 15). Si può anche specificare quale sistema di
 memorizzazione usare per tutte le cache (della vista, del routing e di i18n) in
 `factories.yml`. Il Listato 19-2 mostra la configurazione predefinita della cache della
 vista.
@@ -259,7 +259,7 @@ dei file per accelerare, ma la si può cambiare.
 
 #### Impostazioni di log
 
-Ci sono due impostazioni di log (vedere Capitolo 16) in `settings.yml`:
+Ci sono due impostazioni di log (vedere capitolo 16) in `settings.yml`:
 
   * `error_reporting` specifica quali eventi inserire nei log di PHP. La sua impostazione
     predefinita è `E_PARSE | E_COMPILE_ERROR | E_ERROR | E_CORE_ERROR | E_USER_ERROR` per
@@ -281,7 +281,7 @@ percorsi:
 #### Helper predefiniti
 
 Gli helper predefiniti, caricati per ogni template, sono dichiarati nell'impostazione
-`standard_helpers` (vedere Capitolo 7). I predefiniti sono i gruppi `Partial` e `Cache`.
+`standard_helpers` (vedere capitolo 7). I predefiniti sono i gruppi `Partial` e `Cache`.
 Se si usano altri gruppi di helper in tutti i template di un'applicazione, aggiungere i
 loro nomi all'impostazione `standard_helpers` fa risparmiare la dichiarazione ripetuta di
 `use_helper()` in ogni template.
@@ -304,7 +304,7 @@ Definito nell'impostazione `charset`, il valore predefinito (e consigliato) è `
 >Aggiungere le proprie impostazioni
 >
 >Il file `settings.yml` definisce le impostazioni di symfony per un'applicazione. Come
->discusso nel Capitolo 5, quando si vogliono aggiungere nuovi parametri, il posto migliore
+>discusso nel capitolo 5, quando si vogliono aggiungere nuovi parametri, il posto migliore
 >per farlo è il file `frontend/config/app.yml`. Questo file è anche dipendente
 >dall'ambiente e le impostazioni che vi sono definite sono disponibili tramite la classe
 >`sfConfig` col prefisso `app_`.
@@ -325,7 +325,7 @@ Definito nell'impostazione `charset`, il valore predefinito (e consigliato) è `
 Estendere l'autocaricamento
 ---------------------------
 
-L'autocaricamento, spiegato brevemente nel Capitolo 2, evita di dover richiedere ogni
+L'autocaricamento, spiegato brevemente nel capitolo 2, evita di dover richiedere ogni
 volta le classi, se sono inserite in cartelle specifiche. Questo vuol dire che si può
 lasciare che il framework faccia il lavoro per noi, consentendogli di caricare solo le
 classi necessarie nel momento opportuno e solo quando necessario.
@@ -429,7 +429,7 @@ metodo di autocaricamento di symfony (e usa i posti definiti in `autoload.yml`).
 trova una definizione di classe, tutti gli altri callable registrati con
 `spl_autoload_register()` saranno richiamati, finché la classe non viene trovata. Quindi
 si possono aggiungere quanti meccanismi di autocaricamento si vuole, ad esempio per
-fornire sistemi di aggancio con componenti di altri framework (vedere Capitolo 17).
+fornire sistemi di aggancio con componenti di altri framework (vedere capitolo 17).
 
 Struttura dei file personalizzata
 ---------------------------------
diff --git a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
index 92481f6..d8469dc 100644
--- a/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
+++ b/gentle-introduction/it/A-Inside-the-Model-Layer-Propel.markdown
@@ -8,7 +8,7 @@ Questo capitolo spiega come creare un modello di dati a oggetti e come accedere
 Perché usare un ORM e un livello per l'astrazione?
 --------------------------------------------------
 
-I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM) ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
+I database sono relazionali. PHP 5 e symfony sono orientati agli oggetti. Per poter accedere nel modo più efficace al database in un contesto orientato agli oggetti, è indispensabile una interfaccia per tradurre la logica degli oggetti nella logica relazionale. Come spiegato nel capitolo 1, questa interfaccia è chiamata Object-Relational Mapping (ORM), ed è costituita di oggetti che forniscono l'accesso ai dati e mantengono le business rules all'interno di se stessi.
 
 Il vantaggio principale di un ORM è la riusabilità, che consente ai metodi di un oggetto di tipo dato, di essere chiamato da varie parti dell'applicazione, anche da diverse applicazioni. Il livello ORM incapsula anche la logica dei dati, ad esempio, il calcolo del punteggio degli utenti di un forum basato su quanti contributi sono stati fatti e quanto sono popolari. Quando una pagina deve visualizzare un tale punteggio degli utenti, basta chiamare semplicemente un metodo nel modello dei dati, senza preoccuparsi dei dettagli del calcolo. Se in seguito bisogna modificare il calcolo, sarà sufficiente modificare il metodo nel modello, lasciando il resto dell'applicazione invariata.
 
@@ -48,7 +48,7 @@ Symfony usa Propel o Doctrine come ORM, e questi usano oggetti PHP per l'astrazi
 >In un progetto symfony, tutte le applicazioni condividono lo stesso modello. Questo è un punto fondamentale a livello di progetto: raggruppare le applicazioni che si basano su regole di business comuni. Questa è la ragione per cui il modello è indipendente dalle applicazioni e i file del modello sono memorizzati in una cartella `lib/model/` nella radice del progetto.
 
 Lo schema del database di symfony
--------------------------
+---------------------------------
 
 Allo scopo di creare il modello a oggetti dei dati che symfony userà, bisogna tradurre tutti i modelli relazionali del database in un modello dati a oggetti. L'ORM ha bisogno di una descrizione del modello relazionale per fare la mappatura e questo è chiamato schema. In uno schema si definiscono le tabelle, le relazioni e le caratteristiche delle colonne.
 
@@ -99,18 +99,18 @@ Una tabella può avere attributi speciali, incluso `phpName` (il nome della clas
 
 Una tabella contiene colonne. Il valore delle colonne può essere definito in tre differenti modi:
 
-  * Se non definisci nulla (`~` in YAML equivale a `null` in PHP), symfony indovinerà i migliori attributi in base al nome della colonna e alcune convenzioni che saranno descritte nella sezione "Colonne vuote" più avanti in questo capitolo. Per esempio, la colonna `id` nel Listato 8-3 non ha bisogno di essere definita: Symfony la renderà un intero auto incrementale, chiave primaria della tabella. La colonna `blog_article_id` nella tabella `blog_comment` sarà capita come una chiave esterna verso la tabella `blog_article` (le colonne che terminano con `_id` sono considerate chiave esterne, e la tabella collegata è determinata automaticamente a seconda della prima parte del nome della colonna). Le colonne chiamate `created_at` sono automaticamente impostate al tipo `timestamp`. Per queste colonne, non devi specificare nessun tipo. Questo è il motivo per cui `schema.yml` è così semplice da scrivere.
+  * Se non definisci nulla (`~` in YAML equivale a `null` in PHP), symfony indovinerà i migliori attributi in base al nome della colonna e alcune convenzioni che saranno descritte nella sezione "Colonne vuote" più avanti in questo capitolo. Per esempio, la colonna `id` nel Listato 8-3 non ha bisogno di essere definita: Symfony la renderà un intero auto incrementale, chiave primaria della tabella. La colonna `blog_article_id` nella tabella `blog_comment` sarà capita come una chiave esterna verso la tabella `blog_article` (le colonne che terminano con `_id` sono considerate chiave esterne, e la tabella collegata è determinata automaticamente a seconda della prima parte del nome della colonna). Le colonne chiamate `created_at` sono automaticamente impostate al tipo `timestamp`. Per queste colonne, non occorre specificare nessun tipo. Questo è il motivo per cui `schema.yml` è così semplice da scrivere.
 
-  * Se definisci soltanto un attributo, questo sarà il tipo della colonna. Symfony conosce i classici tipi: `boolean`, `integer`, `float`, `date`, `varchar(lunghezza)`, `longvarchar` (convertito, per esempio, a `text` in MySQL), e così via. Per stringhe superiori ai 256 caratteri devi usare il valore `longvarchar` che non ha lunghezza (ma non può eccedere 65KB in MySQL).
+  * Se definisci soltanto un attributo, questo sarà il tipo della colonna. Symfony conosce i classici tipi: `boolean`, `integer`, `float`, `date`, `varchar(lunghezza)`, `longvarchar` (convertito, per esempio, a `text` in MySQL), e così via. Per stringhe superiori ai 256 caratteri occorre usare il valore `longvarchar`, che non ha lunghezza (ma non può eccedere 65KB in MySQL).
 
-  * Se hai bisogno di definire altri attributi (come il valore di default, se il campo è obbligatorio, e così via), dovresti scrivere gli attributi della colonna come un insieme di `chiave: valore`. Questa sintassi estesa è spiegata più avanti nel capitolo.
+  * Se occorre definire altri attributi (come il valore di default, se il campo è obbligatorio, e così via), si dovrebbero scrivere gli attributi della colonna come un insieme di `chiave: valore`. Questa sintassi estesa è spiegata più avanti nel capitolo.
 
 Le colonne possono avere un attributi `phpName`, che è la versione con prima lettera maiuscola del nome (`Id`, `Title`, `Content`, e così via) e non ha bisogno di essere specificata nella maggior parte dei casi.
 
 Le tabelle possono inoltre contenere esplicite chiavi esterne e indici, come anche alcune definizioni specifiche per alcuni database. Controlla la sezione `Sintassi estesa dello schema` più avanti in questo capitolo per saperne di più.
 
 Le classi del modello
--------------
+---------------------
 Lo schema è usato per costruire le classi del modello nel livello ORM. Per risparmiare tempo di esecuzione, queste classi sono generate con un task a riga di comando chiamato `propel:build-model`.
 
     $ php symfony propel:build-model
@@ -146,7 +146,7 @@ D'altra parte, le classi di oggetti personalizzati presenti nella cartella `lib/
 
 Il Listato 8-4 mostra un esempio di una classe personalizzata del modello, così come viene creata dopo la prima chiamata del task `propel:build-model`.
 
-Listing 8-4 - Esempio di file di una classe del modello, in `lib/model/Article.php`
+Listato 8-4 - Esempio di file di una classe del modello, in `lib/model/Article.php`
 
     [php]
     class Article extends BaseArticle
@@ -168,7 +168,7 @@ Listato 8-5 - Getter per colonne dei record sono disponibili nelle classi oggett
     // ...
     $title = $article->getTitle();
 
-`ArticlePeer` e `CommentPeer` sono classi peer; ovvero, classi che contengono metodi statici che operano sulle tabelle. Possono fornire un modo per recuperare righe dalle tabelle. I loro metodi ritornano solitamente un oggetto o collezione di oggetti della collegata classe oggetto, come mostrato nel Listato 8-6.
+`ArticlePeer` e `CommentPeer` sono classi peer; ovvero, classi che contengono metodi statici che operano sulle tabelle. Possono fornire un modo per recuperare righe dalle tabelle. I loro metodi restituiscono solitamente un oggetto o collezione di oggetti della collegata classe oggetto, come mostrato nel Listato 8-6.
 
 Listato 8-6 - Metodi statici per recuperare record sono disponibili nelle classi peer
 
@@ -179,7 +179,7 @@ Listato 8-6 - Metodi statici per recuperare record sono disponibili nelle classi
 >**NOTE**
 >Da un punto di vista di modello di dati, non potrebbe esserci un oggetto peer. Per questo che i metodi delle classi peer sono chiamati con `::` (operatore per metodi statici), al posto del solito `->` (per le chiamate a metodi d'istanza).
 
-Per questo combinare classi oggetto e peer, base e personalizzate risulta in quattro classi generate per ogni tabella descritta nello schema. A dir la verità, c'è una quinta classe creata nella directory `lib/model/map/`, che contiene metadati riguardo le tabelle ed è necessaria per l'ambiente di esecuzione. Ma dato che probabilmente non si avrà mai a che fare con questa classe, ce ne si può tranquillamente dimenticare.
+Per questo combinare classi oggetto e peer, base e personalizzate risulta in quattro classi generate per ogni tabella descritta nello schema. A dir la verità, c'è una quinta classe creata nella cartella `lib/model/map/`, che contiene metadati riguardo le tabelle ed è necessaria per l'ambiente di esecuzione. Ma dato che probabilmente non si avrà mai a che fare con questa classe, ce ne si può tranquillamente dimenticare.
 
 Accesso ai dati
 ---------------
@@ -211,7 +211,7 @@ Listato 8-7 - Metodi generati nella classe dell'oggetto
 >**NOTE**
 >La classe oggetto generata si chiama `Article`, che è il `phpName` dato alla tabella `blog_article`. Se `phpName` non è stato definito nello schema, la classe sarebbe stata chiamata `BlogArticle`. Gli accessori e modificatori usano una variante camelCase del nome delle colonne, quindi il metodo `getTitle()` resituirà il valore della colonna `title`.
 
-Impostare diversi valori in un unica volta, si può usare il metodo `fromArray()`, generato per ogni classe oggetto, come mostrato nel Listato 8-8.
+Per impostare diversi valori in una sola volta, si può usare il metodo `fromArray()`, generato per ogni classe oggetto, come mostrato nel Listato 8-8.
 
 Listato 8-8 - Il metodo `fromArray()` è un setter multiplo
 
@@ -265,7 +265,7 @@ Listato 8-10 - Chiavi esterne sono trasformate in speciali getter
     // Relazione uno-a-molti
     $comments = $article->getComments();
 
-Il metodo `getArticle()` ritorna un oggetto di classe `Article`, con i benefici del metodo accessore `getTitle()`. Questo è molto migliore di dover eseguire la join tu stesso, che potrebbe richiedere alcune linee di codice (a partire dalla riga `$comment->getArticleId()`).
+Il metodo `getArticle()` restituisce un oggetto di classe `Article`, con i benefici del metodo accessore `getTitle()`. Questo è molto migliore di dover eseguire la join tu stesso, che potrebbe richiedere alcune linee di codice (a partire dalla riga `$comment->getArticleId()`).
 
 La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe `Comment`. Si può mostrare il primo con `$comments[0]` o iterare sulla collezione con `foreach ($comments as $comment)`.
 
@@ -274,7 +274,7 @@ La variabile `$comments` nel listato 8-10 contiene un array di oggetti di classe
 
 ### Salvare ed eliminare dati
 
-Chiamando il costruttore con `new`, hai creato un nuovo oggetto, ma non un record nella tabella `blog_article`. Nemmeno modificare l'oggetto ha effetto sul database. Per salvare dati nel database, devi chiamare il metodo `save()` sull'oggetto.
+Chiamando il costruttore con `new`, un nuovo oggetto è stato creato, ma non un record nella tabella `blog_article`. Nemmeno modificare l'oggetto ha effetto sul database. Per salvare dati nel database, occorre chiamare il metodo `save()` sull'oggetto.
 
     [php]
     $article->save();
@@ -297,14 +297,14 @@ Listato 8-11 - Cancellare righe dal database con il metodo `delete()` dell'ogget
 >**TIP**
 >Anche dopo aver chiamato il metodo `delete()`, un oggetto rimane disponibile fino alla fine dell'esecuzione. Per determinare se un oggetto è stato cancellato dal database, chiama il metodo `isDeleted()`.
 
-### Recuperare record usando la chiave primaria
+### Recuperare record tramite chiave primaria
 
-Se conosci la chiave primaria di un particolare record, usa il metodo `retrieveByPk()` della classe peer per ottenere il relativo oggetto.
+Se si conosce la chiave primaria di un certo record, usare il metodo `retrieveByPk()` della classe peer per ottenere il relativo oggetto.
 
     [php]
     $article = ArticlePeer::retrieveByPk(7);
 
-Il file `schema.yml` definisce il campo `id` come la chiave primaria della tabella `blog_article`, quindi questo comando ritornerà un articolo che ha `id` uguale a 7. Dato che hai utilizzato la chiave primaria, sai che soltanto un record sarà ritornato; la variabile `$article` contiene un oggetto della classe `Article`.
+Il file `schema.yml` definisce il campo `id` come la chiave primaria della tabella `blog_article`, quindi questo comando restituisce un articolo che ha `id` uguale a 7. Dato che è stata usata la chiave primaria, sappiamo che soltanto un record sarà restituito; la variabile `$article` contiene un oggetto della classe `Article`.
 
 In alcuni casi, una chiave primaria può consistere in più di una colonna. In questi casi, il metodo `retrieveByPk()` accetta parametri multipli, uno per ogni colonna della chiave primaria.
 
@@ -316,7 +316,7 @@ Quando si vuole recuperare più di un record, occorre utilizzare il metodo `doSe
 
 Il primo parametro del metodo `doSelect()` è un oggetto della classe `Criteria`, che è una semplice classe per la costruzione delle query, senza l'utilizzo di SQL per mantenere l'astrazione dal database.
 
-Un oggetto `Criteria` vuoto ritorna tutti gli oggetti della classe. Per esempio, il codice mostrato nel Listato 8-12 ritorna tutti gli articoli.
+Un oggetto `Criteria` vuoto restituisce tutti gli oggetti della classe. Per esempio, il codice mostrato nel Listato 8-12 restituisce tutti gli articoli.
 
 Listato 8-12 - Recuperare record usando Criteria e `doSelect()`--Criteria vuoto
 
@@ -332,7 +332,7 @@ Listato 8-12 - Recuperare record usando Criteria e `doSelect()`--Criteria vuoto
 >**SIDEBAR**
 >Idratazione
 >
->La chiamata a `::doSelect()` è a dir la verità molto più potente di una semplice query SQL. Per prima cosa, il codice SQL generato è ottimizzato per il DBMS scelto. Secondo, su ogni valore passato a `Criteria` viene effettuato l'escape prima di venir intergrato nel codice SQL, che previene rischi di SQL injection. Terzo, questo metodo ritorna un array di oggetti piuttosto che una risorsa PHP. L'ORM crea automaticamente gli oggetti basandosi sulla risorsa ritornata dal database. Questo processo è chiamato idratazione.
+>La chiamata a `::doSelect()` è a dir la verità molto più potente di una semplice query SQL. Per prima cosa, il codice SQL generato è ottimizzato per il DBMS scelto. Secondo, su ogni valore passato a `Criteria` viene effettuato l'escape prima di venir intergrato nel codice SQL, che previene rischi di SQL injection. Terzo, questo metodo restituisce un array di oggetti piuttosto che una risorsa PHP. L'ORM crea automaticamente gli oggetti basandosi sulla risorsa restituita dal database. Questo processo è chiamato idratazione.
 
 Per una selezione più complessa, avrai bisogno degli equivalenti di WHERE, ORDER BY, GROUP BY e altre istruzioni SQL. L'oggetto `Criteria` ha metodi e parametri per tutte queste condizioni. Per esempio, per ottenere tutti i commenti scritti da Steve, ordinati per data, costruisci un `Criteria` come mostrato nel Listato 8-13.
 
@@ -354,7 +354,7 @@ Listato 8-13 - Recuperare record usando Criteria e `doSelect()`--Criteria con co
 Le costanti di classe passate come parametri dei metodi `add()` si riferiscono ai nomi delle propietà. Sono chiamate con la versione maiuscola dei nomi delle colonne. Per esempio, per la colonna `content` della tabella `blog_article`, usa la costante `ArticlePeer::CONTENT`.
 
 >**NOTE**
->Perché usare `CommentPeer::AUTHOR` al posto di `blog_comment.AUTHOR`, che è quello che sarà utilizzato nel codice SQL in ogni caso? Supponi di dover cambiare il nome della colonna da `author` a `contributor` nel database. Se tu avessi usato `blog_comment.AUTHOR`, dovresti cambiarlo a ogni chiamata del metodo. Invece, usando `CommentPeer::AUTHOR`, devi soltanto cambiare il nome della colonna nel file `schema.yml`, impostare il valore `phpName` ad `AUTHOR` e ricostruire il modello.
+>Perché usare `CommentPeer::AUTHOR` al posto di `blog_comment.AUTHOR`, che è quello che sarà utilizzato nel codice SQL in ogni caso? Supponi di dover cambiare il nome della colonna da `author` a `contributor` nel database. Se tu avessi usato `blog_comment.AUTHOR`, dovresti cambiarlo a ogni chiamata del metodo. Invece, usando `CommentPeer::AUTHOR`, occorre soltanto cambiare il nome della colonna nel file `schema.yml`, impostare il valore `phpName` ad `AUTHOR` e ricostruire il modello.
 
 La Tabella 8-1 confronta la sintassi SQL con quella della classe `Criteria`.
 
@@ -380,11 +380,11 @@ SQL                                                          | Criteria
 `FROM table1 RIGHT JOIN table2 ON table1.col1 = table2.col2` | `->addJoin(col1, col2, Criteria::RIGHT_JOIN)`
 
 >**TIP**
->Il modo migliore per scoprire e capire quali metodi sono disponibili nelle classi generate è guardare ai file `Base` nella cartella `lib/model/om/` dopo la generazione. I nomi dei metodi sono abbastanza espliciti, ma se hai bisogno di commenti in essi imposta il parametro `propel.builder.addComments` a `true` nel file `config/propel.ini` e ricostruisci il modello.
+>Il modo migliore per scoprire e capire quali metodi sono disponibili nelle classi generate è guardare ai file `Base` nella cartella `lib/model/om/` dopo la generazione. I nomi dei metodi sono abbastanza espliciti, ma se servono dei commenti in essi si può impostare il parametro `propel.builder.addComments` a `true` nel file `config/propel.ini` e ricostruire il modello.
 
 Il Listato 8-14 mostra un altro esempio di `Criteria` con condizioni multiple. Recupera tutti i commenti di Steve sugli articoli contenenti la parola "enjoy", ordinati per data.
 
-Listato 8-14 - Un altro esempio di recuperato record con Criteria e `doSelect()`--Criteria con condizioni
+Listato 8-14 - Un altro esempio di record recuperato con Criteria e `doSelect()`--Criteria con condizioni
 
     [php]
     $c = new Criteria();
@@ -405,29 +405,29 @@ Listato 8-14 - Un altro esempio di recuperato record con Criteria e `doSelect()`
 
 Come SQL è un linguaggio semplice che consente di gestire interrogazioni molto complesse, l'oggetto Criteria può gestire condizioni con ogni livello di complessità. Ma dato che molti sviluppatori pensano in SQL prima di tradurre una condizione in logica object-oriented, l'oggetto `Criteria` può essere difficile da comprendere all'inizio. Il miglior modo di capirlo è imparare dagli esempi e applicazioni esistenti. Il sito di symfony, per esempio, è pieno di esempi di utilizzo di `Criteria` che ti aiuteranno in molte situazioni.
 
-In aggiunta al metodo `doSelect()`, ogni classe peer ha un metodo `doCount()`, che semplicemente ritorna il numero di record che soddisfano i requisiti passati come parametri e ritorna un numero intero. Dato che nessun oggetto viene ritornato, il processo di idratazione non viene eseguito in questo caso, perciò il metodo `doCount()` è più veloce di `doSelect()`.
+In aggiunta al metodo `doSelect()`, ogni classe peer ha un metodo `doCount()`, che semplicemente restituiscono il numero di record che soddisfano i requisiti passati come parametri e restituisce un numero intero. Dato che nessun oggetto viene restituito, il processo di idratazione non viene eseguito in questo caso, perciò il metodo `doCount()` è più veloce di `doSelect()`.
 
-La classi peer forniscono inoltre i metodi `doDelete()`, `doInsert()` e `doUpdate()`, che ricevono un oggetto `Criteria` come parametro. Questi metodi consentono di eseguire interrogazioni di tipo `DELETE`, `INSERT` e `UPDATE` sul database. Dai un'occhiata alle classi peer generate nel tuo modello per ulteriori dettagli su questi metodi di Propel.
+La classi peer forniscono inoltre i metodi `doDelete()`, `doInsert()` e `doUpdate()`, che ricevono un oggetto `Criteria` come parametro. Questi metodi consentono di eseguire interrogazioni di tipo `DELETE`, `INSERT` e `UPDATE` sul database. Dare un'occhiata alle classi peer generate nel modello per ulteriori dettagli su questi metodi di Propel.
 
-Infine, se si vuole soltanto il primo oggetto, sostituire `doSelect()` con `doSelectOne()`. Questo potrebbe essere il caso in cui si sa che `Criteria` produrrà un risultato soltanto, con il vantaggio che il metodo ritornerà direttamente un oggetto piuttosto di un array.
+Infine, se si vuole soltanto il primo oggetto, sostituire `doSelect()` con `doSelectOne()`. Questo potrebbe essere il caso in cui si sa che `Criteria` produrrà un risultato soltanto, con il vantaggio che il metodo restuituirà direttamente un oggetto piuttosto di un array.
 
 >**TIP**
->Quando una query ritorna un gran numero di risultati, potresti volerne mostrare soltanto un sottoinsieme. Symfony fornisce una classe per la suddivisione in pagine chiamata `sfPropelPager`, che automatizza la paginazione dei risultati.
+>Quando una query restituisce un gran numero di risultati, si potrebbe volerne mostrare soltanto un sottoinsieme. Symfony fornisce una classe per la suddivisione in pagine chiamata `sfPropelPager`, che automatizza la paginazione dei risultati.
 
 ### Usare query SQL
 
-A volte, non ti serve recuperare oggetti, ma vuoi soltanto risultati sintetici calcolati dal database. Per esempio, per ottenere l'ultima data di creazione di tutti gli articoli, non ha senso recuperare tutti gli articoli ed eseguire un ciclo sull'array. È preferibile richiedere direttamente al database di ritornare soltanto il risultato, perché salterà il processo di idratazione.
+A volte non serve recuperare oggetti, ma soltanto avere risultati sintetici calcolati dal database. Per esempio, per ottenere l'ultima data di creazione di tutti gli articoli, non ha senso recuperare tutti gli articoli ed eseguire un ciclo sull'array. È preferibile richiedere direttamente al database di restituire soltanto il risultato, perché salterà il processo di idratazione.
 
-D'altra parte, non è il caso di usare i comandi PHP per gestire direttamente il database, perché perderesti i vantaggi dell'astrazione dal database. Questo significa che hai bisogno di bypassare l'ORM (Propel) ma non l'astrazione dal database (PDO).
+D'altra parte, non è il caso di usare i comandi PHP per gestire direttamente il database, perché perderesti i vantaggi dell'astrazione dal database. Questo significa che occorre aggirare l'ORM (Propel) ma non l'astrazione dal database (PDO).
 
-Una query al database con PHP Data Objects richiede che tu faccia il seguente:
+Una query al database con PHP Data Objects richiede i seguentii passi:
 
-  1. Ottieni una connessione al database
-  2. Crea una query
-  3. Usala per creare uno "statement"
-  4. Cicla sul risultato dell'esecuzione dello statement
+  1. Ottienre una connessione al database
+  2. Creare una query
+  3. Usarla per creare uno "statement"
+  4. Ciclare sul risultato dell'esecuzione dello statement
 
-Se queste sembrano parole campate in aria per te, il codice del Listato 8-15 probabilmente sarà più esplicito.
+Se queste sembrano parole campate in aria, il codice del Listato 8-15 probabilmente sarà più esplicito.
 
 Listato 8-15 - Query SQL personalizzata con PDO
 
@@ -441,16 +441,16 @@ Listato 8-15 - Query SQL personalizzata con PDO
     $resultset = $statement->fetch(PDO::FETCH_OBJ);
     $max = $resultset->max;
 
-Proprio come le selezioni con Propel, le query con PDO sono complesse la prima volta che inizi ad usarle. Ma anche stavolta, esempi da applicazioni esistenti e tutorial ti mostreranno il modo giusto.
+Proprio come le selezioni con Propel, le query con PDO sono complesse quando si inizia a usarle. Ma anche stavolta, esempi da applicazioni esistenti e tutorial mostreranno il modo giusto.
 
 >**CAUTION**
->Se sei tentato di bypassare questo processo ed accedere al database direttamente, rischi di perdere la sicurezza ed astrazione fornita da Propel. Facendo in questo modo, ma ti forza ad usare le migliori pratiche per garantire performance, portabilità, e sicurezza della tua applicazione. Questo è specialmente vero per query che contengono parametri che arrivano da una fonte non sicura (come ad esempio l'utente). Propel fa tutto il lavoro necessario per mettere al sicuro il tuo database. Accedere al database dirttamente ti mette a rischio di attacchi di tipo SQL-injection.
+>Se si è tentati di aggirare questo processo e accedere al database direttamente, si rischia di perdere la sicurezza e l'astrazione fornite da Propel. Facendo in questo modo si impiega di più, ma costinge a usare le migliori pratiche per garantire prestazioni, portabilità e sicurezza della propria applicazione. Questo è vero specialmente per query che contengono parametri che arrivano da una fonte non sicura (come ad esempio l'utente). Propel fa tutto il lavoro necessario per mettere al sicuro il database. Accedere al database dirttamente mette a rischio di attacchi di tipo SQL-injection.
 
-### Usare colonne di tipo data speciali
+### Uso di colonne speciali per le date
 
 Di solito, quando una tabella ha una colonna chiamata `created_at`, è usata per salvare il timestamp della data di quando il record è stato creato. Lo stesso succede per le colonne `updated_at`, che saranno aggiornate ogni volta che il record stesso viene aggiornato.
 
-La buona notizia è che symfony riconoscerà i nomi di queste colonne e gestirà il loro aggiornamento per te. Non avrai bisogno di impostare manualmente i valori di `created_at` e `updated_at`; saranno aggiornati automaticamente, come mostrato nel Listato 8-16. Lo stesso succede per le colonne chiamate `created_on` e `updated_on`.
+La buona notizia è che symfony riconoscerà i nomi di queste colonne e gestirà il loro autonomamente. Non servirò impostare manualmente i valori di `created_at` e `updated_at`, saranno aggiornati automaticamente, come mostrato nel Listato 8-16. Lo stesso succede per le colonne chiamate `created_on` e `updated_on`.
 
 Listato 8-16 - Le colonne `created_at` e `updated_at` sono gestite in automatico
 
@@ -469,11 +469,11 @@ Inoltre, il getter per le colonne di tipo data accetta un formato di data come p
     echo $comment->getCreatedAt('Y-m-d');
 
 >**SIDEBAR**
->Refactoring dello strato di gestione dei dati
+>Rifattorizzazione del livello di gestione dei dati
 >
->Durante lo sviluppo di un progetto symfony, inizierai spesso scrivendo il codice per le azioni sul database nelle azioni. Ma le query al database e manipolazione del modello non dovrebbero risiedere nello strato del controller. Per questo, tutto il codice per la gestione del database dovrebbe essere spostato nel modello. Nel caso avessi bisogno di fare la stessa richiesta al database in più di un punto nelle tue azioni, pensa al trasferire il relativo codice nel modello. Aiuta a tenere le azioni corte e leggibili.
+>Durante lo sviluppo di un progetto symfony, si inizia spesso scrivendo il codice per il database nelle azioni. Ma le query al database e manipolazione del modello non dovrebbero risiedere nel livello del controllore. Per questo, tutto il codice per la gestione del database dovrebbe essere spostato nel modello. Nel caso occorra fare la stessa richiesta al database in più di un punto nelle azioni, si dovrebbe trasferire il relativo codice nel modello. Aiuta a tenere le azioni corte e leggibili.
 >
->Per esempio, immagina il codice in un blog per recuperare i dieci articoli più popolari per un determinato tag (passato come parametro della richiesta). Questo codice non dovrebbe risiedere nell'azione, ma nel modello. Infatti, se avrai bisogno di mostrare questa lista in un template, l'azione dovrebbe essere così semplice:
+>Per esempio, si immagini il codice in un blog per recuperare i dieci articoli più popolari per un determinato tag (passato come parametro della richiesta). Questo codice non dovrebbe risiedere nell'azione, ma nel modello. Infatti, se si avrà bisogno di mostrare questa lista in un template, l'azione dovrebbe essere così semplice:
 >
 >     [php]
 >     public function executeShowPopularArticlesForTag($request)
@@ -483,30 +483,30 @@ Inoltre, il getter per le colonne di tipo data accetta un formato di data come p
 >       $this->articles = $tag->getPopularArticles(10);
 >     }
 >
->L'azione crea un oggetto della classe `Tag` dal parametro di richiesta. Poi, tutto il codice necessario alla query al database è localizzato nel metodo `getPopularArticles()` di questa classe. Rende l'azione più leggibile, ed il codice può essere facilmente riutilizzato in un'altra azione.
+>L'azione crea un oggetto della classe `Tag` dal parametro di richiesta. Poi, tutto il codice necessario alla query al database è localizzato nel metodo `getPopularArticles()` di questa classe. Rende l'azione più leggibile e il codice può essere facilmente riutilizzato in un'altra azione.
 >
->Spostare il codice nel posto più appropriato è una delle tecniche del refactoring. Se lo fai spesso, il tuo codice sarà facilmente mantenibile e comprensibile da altri sviluppatori. Una buona convenzione sul quando fare refactoring verso il modello consiste nel riuscire a mantenere un numero di righe di codice di un azione inferiore a dieci.
+>Spostare il codice nel posto più appropriato è una delle tecniche della rifattorizzazione. Se lo si fa spesso, il proprio codice sarà facilmente mantenibile e comprensibile da altri sviluppatori. Una buona convenzione sul quando rifattorizzare verso il modello consiste nel riuscire a mantenere un numero di righe di codice di un azione inferiore a dieci.
 
 Connessioni al database
---------------------
+-----------------------
 
-Il modello è indipendente dal database usato, ma per forza di cose userai un database. Le informazioni minime richiesta da symfony per inviare richieste al database è il nome, le credenziali di acecsso ed il tipo di database. Queste impostazioni di connessione possono essere configurati passato un data source name (DSN) al processo `configure:database`:
+Il modello è indipendente dal database usato, ma per forza di cose si userà un database. Le informazioni minime richiesta da symfony per inviare richieste al database sono il nome, le credenziali di accesso e il tipo di database. Queste impostazioni di connessione possono essere configurati passando un data source name (DSN) al task `configure:database`:
 
     $ php symfony configure:database "mysql:host=localhost;dbname=blog" root mYsEcret
 
-Le impostazioni di connessione dipendono dall'ambiente di lavoro. Puoi definire configurazioni differenti per gli ambienti `prod`, `dev` e `test`, o per ogni altro ambiente nella tua applicazione usando l'opzione `env`:
+Le impostazioni di connessione dipendono dall'ambiente. Si possono definire configurazioni differenti per gli ambienti `prod`, `dev` e `test`, o per ogni altro ambiente nella propria applicazione usando l'opzione `env`:
 
     $ php symfony configure:database --env=dev "mysql:host=localhost;dbname=blog_dev" root mYsEcret
 
-Questa configurazione può inoltre venir sovrascritta per ogni applicazione. Per esempio, puoi usare questo approccio per avere differenti polizze di sicurezza per le tue applicazioni frontend o backend, e definire utenti del database differenti con privilegi diversi per gestire tutto ciò:
+Questa configurazione può inoltre venir sovrascritta per ogni applicazione. Per esempio, si può usare questo approccio per avere differenti polizze di sicurezza per le tue applicazioni frontend o backend, e definire utenti del database differenti con privilegi diversi per gestire tutto ciò:
 
     $ php symfony configure:database --app=frontend "mysql:host=localhost;dbname=blog" root mYsEcret
 
-Per ogni ambiente, puoi definire differenti connessioni. Ogni connessione si riferisce allo schema chiamato con lo stesso nome. La connessione di default si chiama `propel` e si riferisce allo schema `propel` nel Listato 8-3. L'opzione `name` consente di creare un altra connessione:
+Per ogni ambiente, si possono definire differenti connessioni. Ogni connessione si riferisce allo schema chiamato con lo stesso nome. La connessione predefinita si chiama `propel` e si riferisce allo schema `propel` nel Listato 8-3. L'opzione `name` consente di creare un altra connessione:
 
     $ php symfony configure:database --name=main "mysql:host=localhost;dbname=example" root mYsEcret
 
-Puoi inoltre inserire queste impostazioni di connessione manualmente nel file `databases.yml` collocato nella cartella `config/`. Il Listato 8-17 mostra un esempio di questo file ed il Listato 8-18 mostra lo stesso esempio con la notazione estesa.
+Si possono inoltre inserire queste impostazioni di connessione manualmente nel file `databases.yml` collocato nella cartella `config/`. Il Listato 8-17 mostra un esempio di questo file e il Listato 8-18 mostra lo stesso esempio con la notazione estesa.
 
 Listato 8-17 - Notazione semplice per la connessione al database
 
@@ -552,7 +552,7 @@ I valori consentiti per il parametri `phptype` sono quelli dei database supporta
 
 Per sovrascrivere la configurazione per applicazione, avrai bisogno di modificare il file specifico dell'applicazione, come `apps/frontend/config/databases.yml`.
 
-Se usi un database SQLite, il parametro `hostspec` deve essere impostato al percorso del file del database. Per esempio, se tu tieni il tuo blog in `data/blog.db`, il file `databases.yml` sarà come quello nel Listato 8-19.
+Se usi un database SQLite, il parametro `hostspec` deve essere impostato al percorso del file del database. Per esempio, se si tieni il proprio blog in `data/blog.db`, il file `databases.yml` sarà come quello nel Listato 8-19.
 
 Listato 8-19 - Connessione al database specifica per SQLite usando un percorso file come host
 
@@ -565,15 +565,15 @@ Listato 8-19 - Connessione al database specifica per SQLite usando un percorso f
           database: %SF_DATA_DIR%/blog.db
 
 Estendere il modello
--------------------
+--------------------
 
-I metodi generati del modello sono ottimi, ma spesso non sufficienti. Presto implementerai la tua logica ed avrai bisogno di estenderlo, aggiungendo nuovi metodi oppure sovrascrivendo quelli esistenti.
+I metodi generati del modello sono ottimi, ma spesso non sufficienti. Al momento di implementare la logica, si avrà bisogno di estenderlo, aggiungendo nuovi metodi oppure sovrascrivendo quelli esistenti.
 
 ### Aggiungere nuovi metodi
 
-Puoi aggiugnere nuovi metodi alle classi del modello vuote generate nella cartella `lib/model`. Usa `$this` per chiamare metodi sull'oggetto corrente, mentre usa `self::` per chiamare metodi statici sulla classe corrente. Ricorda che le classi personalizzate ereditano i metodi dalle classi `Base` collocate nella cartella `lib/model/om`.
+Si possono aggiungere nuovi metodi alle classi del modello vuote generate nella cartella `lib/model`. Usare `$this` per chiamare metodi sull'oggetto corrente e usare `self::` per chiamare metodi statici sulla classe corrente. Si ricordi che le classi personalizzate ereditano i metodi dalle classi `Base` collocate nella cartella `lib/model/om`.
 
-Per esempio, per l'oggetto `Article` generato basato sul Listato 8-3, puoi aggiungere un metodo magico `__toString()` per far si che un comando `echo` su un oggetto di classe `Article` mostri il suo titolo, come mostrato nel Listato 8-20.
+Per esempio, per l'oggetto `Article` generato basato sul Listato 8-3, si può aggiungere un metodo magico `__toString()` per far sì che un comando `echo` su un oggetto di classe `Article` mostri il suo titolo, come mostrato nel Listato 8-20.
 
 Listato 8-20 - Personalizzazione del modello, in `lib/model/Article.php`
 
@@ -586,7 +586,7 @@ Listato 8-20 - Personalizzazione del modello, in `lib/model/Article.php`
       }
     }
 
-Puoi inoltre estendere le classi peer, per esempio, per aggiungere un metodo per recuperare tutti gli articoli ordinati per data di creazione, come mostrato nel Listato 8-21.
+Si possono inoltre estendere le classi peer, per esempio, per aggiungere un metodo per recuperare tutti gli articoli ordinati per data di creazione, come mostrato nel Listato 8-21.
 
 Listato 8-21 - Personalizzazione del modello, in `lib/model/ArticlePeer.php`
 
@@ -612,13 +612,13 @@ Listato 8.22 - Usare i metodi personalizzati è come usare i metodi generati
       echo $article;      // Chiamerà il metodo magico __toString()
     }
 
-### Sobrascrivere metodi esistenti
+### Sovrascrivere i metodi esistenti
 
-Se alcuni dei metodi generati nelle classi `Base` non soddisfano i tuoi requisiti, puoi comunque sovrascriverli nelle classi personalizzate. Sii sicuro che abbiano la stessa firma (ovvero lo stesso numero di parametri).
+Se alcuni dei metodi generati nelle classi `Base` non soddisfano i requisiti, si può comunque sovrascriverli nelle classi personalizzate. Assicurarsi che abbiano la stessa firma (ovvero lo stesso numero di parametri).
 
-Per esempio, il metodo `$article->getComments()` ritorna un array di oggetti `Comment`, senza alcun ordine particolare. Se vuoi avere i risultati ordinati per data di creazione, con gli ultimi commenti per primi, allora sovrascrivi il metodo `getComments()`, come mostrato nel Listato 8-23. Sii conscio che il metodo originale `getComments()` (collocato in `lib/model/om/BaseArticle.php`) si aspetta un oggetto Criteria ed una connessione come parametri, quindi la tua funzione deve fare lo stesso.
+Per esempio, il metodo `$article->getComments()` restituisce un array di oggetti `Comment`, senza alcun ordine particolare. Se si vogliono i risultati ordinati per data di creazione, con gli ultimi commenti per primi, sovrascrivere il metodo `getComments()`, come mostrato nel Listato 8-23. Attenzione: il metodo originale `getComments()` (collocato in `lib/model/om/BaseArticle.php`) si aspetta un oggetto `Criteria` e una connessione come parametri, quindi la nuova funzione deve fare lo stesso.
 
-Listato 8-23 - Sovrascivere metodi esistenti del modello, in `lib/model/Article.php`
+Listato 8-23 - Sovrascrivere metodi esistenti del modello, in `lib/model/Article.php`
 
     [php]
     public function getComments($criteria = null, $con = null)
@@ -629,7 +629,7 @@ Listato 8-23 - Sovrascivere metodi esistenti del modello, in `lib/model/Article.
       }
       else
       {
-        // Gli oggetti sono passati per riferimento in PHP5, quindi per evitare di modificare l'originale, devi clonarlo
+        // Gli oggetti sono passati per riferimento in PHP5, quindi per evitare di modificare l'originale, occorre clonarlo
         $criteria = clone $criteria;
       }
       $criteria->addDescendingOrderByColumn(CommentPeer::CREATED_AT);
@@ -637,41 +637,41 @@ Listato 8-23 - Sovrascivere metodi esistenti del modello, in `lib/model/Article.
       return parent::getComments($criteria, $con);
     }
 
-Il metodo personalizzato chiama infine quello della classe Base, ed è una buona pratica. Comunque, puoi completamente bypassarlo e ritornare il risultato che vuoi.
+Il metodo personalizzato chiama infine quello della classe Base ed è una buona pratica. Comunque, lo si può aggirare completamente e restituire il risultato desiderato.
 
 ### Usare i comportamenti (behavior) del modello
 
-Alcune modifiche al modello sono generiche e possono venire riutilizzate. Per esempio, i metodi per rendere un oggetto del modello ordinabile ed un blocco ottimistico per prevenire conflitti tra il salvataggio di oggetti concorrenti sono estensioni generiche che possono venir aggiunte a diverse classi.
+Alcune modifiche al modello sono generiche e possono venire riutilizzate. Per esempio, i metodi per rendere un oggetto del modello ordinabile e un blocco ottimistico per prevenire conflitti tra il salvataggio di oggetti concorrenti sono estensioni generiche che possono venir aggiunte a diverse classi.
 
-Symfony fornisce queste estensioni tramite i behavior. I behavior sono classi esterne che forniscono metodi aggiuntivi alle classi del modello. Le classi del modello contengono già degli "appigli" (hooks), e symfony sa come estenderle.
+Symfony fornisce queste estensioni tramite i behavior. I behavior sono classi esterne che forniscono metodi aggiuntivi alle classi del modello. Le classi del modello contengono già degli "appigli" (hooks) e symfony sa come estenderle.
 
-Per abilitare i behavior nelle tue classi del modello, devi modificare un'impostazione nel file `config/propel.ini`:
+Per abilitare i behavior nelle classi del modello, occorre modificare un'impostazione nel file `config/propel.ini`:
 
     propel.builder.AddBehaviors = true     // Il valore di default è false
 
-Non c'è nessun behavior incluso in symfony di default, ma possono venir installati tramite plugins. Dopo che un behavior è installato, puoi assegnare il behavior ad una classe con una singola istruzione. Per esempio, se installi il plugin `sfPropelParanoidBehaviorPlugin` nella tua applicazione, puoi estendere una classe `Article` con questo behavior aggiungendo queste righe alla fine di `Article.class.php`:
+Non c'è nessun behavior incluso in symfony di default, ma possono essere installati tramite plugin. Dopo che un behavior è installato, si può assegnare il behavior a una classe con una singola istruzione. Per esempio, se si installa il plugin `sfPropelParanoidBehaviorPlugin` nella propria applicazione, si può estendere una classe `Article` con questo behavior, aggiungendo queste righe alla fine di `Article.class.php`:
 
     [php]
     sfPropelBehavior::add('Article', array(
       'paranoid' => array('column' => 'deleted_at')
     ));
 
-Dopo aver ricostruito il modello, gli oggetti `Article` eliminati resteranno nel database, invisibile alle query creato usando l'ORM, a meno che non disabiliti temporaneamente il behavior con `sfPropelParanoidBehavior::disable()`.
+Dopo aver ricostruito il modello, gli oggetti `Article` eliminati resteranno nel database, invisibile alle query create usando l'ORM, a meno che non si disabiliti temporaneamente il behavior con `sfPropelParanoidBehavior::disable()`.
 
-In alternativa, puoi inoltre dichiarare behaviors direttamente dentro a `schema.yml`, aggiungendoli all'interno della chiave `_behaviors` (vedi il Listato 8-34 di seguito).
+In alternativa, si possono dichiarare i behavior direttamente dentro allo `schema.yml`, aggiungendoli all'interno della chiave `_behaviors` (vedere il Listato 8-34 di seguito).
 
-Controlla la lista dei plugin di symfony sul [repository](http://www.symfony-project.org/plugins/) ufficiale per trovare i behavior. Ognuno ha la sua documentazione e guida di installazione.
+Controllare la lista dei plugin di symfony sul [repository](http://www.symfony-project.org/plugins/) ufficiale per trovare i behavior. Ognuno ha la sua documentazione e guida di installazione.
 
-Extended Schema Syntax
-----------------------
+Sintassi estesa dello schema
+----------------------------
 
-A `schema.yml` file can be simple, as shown in Listing 8-3. But relational models are often complex. That's why the schema has an extensive syntax able to handle almost every case.
+Un file `schema.yml` può essere semplice, come mostrato nel Listato 8-3. Ma i modelli relazionali sono spesso complessi. Per questo lo schema ha una sinstassi estesa, che consente di gestire quasi tutti i casi.
 
-### Attributes
+### Attributi
 
-Connections and tables can have specific attributes, as shown in Listing 8-24. They are set under an `_attributes` key.
+Le connessioni e le tabelle possono avere attributi specifici, come mostrato nel Listato 8-24. Questi sono sotto la chiave `_attributes`.
 
-Listing 8-24 - Attributes for Connections and Tables
+Listato 8-24 - Attributi per connessioni e tabelle
 
     [yml]
     propel:
@@ -679,15 +679,15 @@ Listing 8-24 - Attributes for Connections and Tables
       blog_article:
         _attributes: { phpName: Article }
 
-You may want your schema to be validated before code generation takes place. To do that, deactivate the `noXSD` attribute for the connection. The connection also supports the `defaultIdMethod` attribute. If none is provided, then the database's native method of generating IDs will be used--for example, `autoincrement` for MySQL, or `sequences` for PostgreSQL. The other possible value is `none`.
+Si potrebbe voler validare lo schema prima di eseguire la generazione. Per farlo, disattivare l'attributo `noXSD` della connessione. La connessione supporta anche un attributo `defaultIdMethod`. Se non viene fornito, sarà usato il metodo nativo di generazione di ID, ad esempio `autoincrement` per MySQL o `sequences` per PostgreSQL. L'altro possibile valore è `none`.
 
-The `package` attribute is like a namespace; it determines the path where the generated classes are stored. It defaults to `lib/model/`, but you can change it to organize your model in subpackages. For instance, if you don't want to mix the core business classes and the classes defining a database-stored statistics engine in the same directory, then define two schemas with `lib.model.business` and `lib.model.stats` packages.
+L'attributo `package` è come un namespace: esso determina il percorso in cui mettere le classi generate. Il valore predefinito è `lib/model/`, ma lo si può cambiare per organizzare i modelli in pacchetti. Ad esempio, se non si vogliono mischiare le classi in una sola cartella, si possono definire due schemi: `lib.model.business` e `lib.model.stats`.
 
-You already saw the `phpName` table attribute, used to set the name of the generated class mapping the table.
+Abbiamo già visto l'attributo delle tabelle `phpName`, usato per impostare il nome della classe generata riferita a una tabella.
 
-Tables that contain localized content (that is, several versions of the content, in a related table, for internationalization) also take two additional attributes (see Chapter 13 for details), as shown in Listing 8-25.
+Le tabelle contenenti dati localizzati (cioè diverse versioni dello stesso contenuto, in una tabella correlata, per l'internazionalizzazione) posso accettare due ulteriori parametri (si veda il capitolo 13 per i dettagli), come mostrato nel Listato 8-25.
 
-Listing 8-25 - Attributes for i18n Tables
+Listato 8-25 - Attributi per le tabelle i18n
 
     [yml]
     propel:
@@ -695,11 +695,11 @@ Listing 8-25 - Attributes for i18n Tables
         _attributes: { isI18N: true, i18nTable: db_group_i18n }
 
 >**SIDEBAR**
->Dealing with multiple Schemas
+>Gestire schemi multipli
 >
->You can have more than one schema per application. Symfony will take into account every file ending with `schema.yml` or `schema.xml` in the `config/` folder. If your application has many tables, or if some tables don't share the same connection, you will find this approach very useful.
+>Si può avere più di uno schema per applicazione. Symfony considererà ogni file il cui nome finisce per `schema.yml` o `schema.xml` nella cartella `config/`. Se l'applicazione ha molte tabelle o se alcune tabelle non condividono la stessa connessione, questo approccio può essere molto utile.
 >
->Consider these two schemas:
+>Si considerino questi due schemi:
 >
 >     [yml]
 >     // In config/business-schema.yml
@@ -718,10 +718,9 @@ Listing 8-25 - Attributes for i18n Tables
 >         created_at:
 >
 >
->Both schemas share the same connection (`propel`), and the `Article` and `Hit` classes will be generated under the same `lib/model/` directory. Everything happens as if you had written only one schema.
->
->You can also have different schemas use different connections (for instance, `propel` and `propel_bis`, to be defined in `databases.yml`) and organize the generated classes in subdirectories:
+>Entrambi gli schemi condividono la stessa connessione (`propel`) e le classi `Article` e `Hit` saranno generate sotto la stessa cartella `lib/model/`. È tutto come se avessimo un unico schema.
 >
+>Si possono anche avere schemi diversi per connessioni diverse (per esempio, `propel` e `propel_bis`, da definire in `databases.yml`) e organizzare le classi generate in sotto-cartelle:
 >
 >     [yml]
 >     // In config/business-schema.yml
@@ -740,23 +739,23 @@ Listing 8-25 - Attributes for i18n Tables
 >         created_at:
 >
 >
->Many applications use more than one schema. In particular, some plug-ins have their own schema and package to avoid messing with your own classes (see Chapter 17 for details).
+>Diverse applicazioni usano più di uno schema. In particolare, alcuni plugin hanno il loro schema e il loro `package`, per evitare di confondersi con le classi del progetto (si veda il capitolo 17 per i dettagli).
 
-### Column Details
+### Dettagli delle colonne
 
-The basic syntax gives you two choices: let symfony deduce the column characteristics from its name (by giving an empty value) or define the type with one of the type keywords. Listing 8-26 demonstrates these choices.
+La sintassi di base fornisce due scelte: lasciare che symfony deduca le caratteristiche delle colonne dal loro nome (dando un valore vuoto) o definire il tipo con una della chiavi. Il Listato 8-26 mostra queste scelte.
 
-Listing 8-26 - Basic Column Attributes
+Listato 8-26 - Attributi di base delle colonne
 
     [yml]
     propel:
       blog_article:
-        id:    ~            # Let symfony do the work
-        title: varchar(50)  # Specify the type yourself
+        id:    ~            # symfony fa da solo
+        title: varchar(50)  # specificato
 
-But you can define much more for a column. If you do, you will need to define column settings as an associative array, as shown in Listing 8-27.
+Ma si può definire di più per una colonna. Se si vuole, occorre definire le impostazioni della colonna come array associativo, come mostrato nel Listato 8-27.
 
-Listing 8-27 - Complex Column Attributes
+Listato 8-27 - Attributi complessi delle colonne
 
     [yml]
     propel:
@@ -765,27 +764,27 @@ Listing 8-27 - Complex Column Attributes
         name:     { type: varchar(50), default: foobar, index: true }
         group_id: { type: integer, foreignTable: db_group, foreignReference: id, onDelete: cascade }
 
-The column parameters are as follows:
+I parametri delle colonne sono i seguenti:
 
-  * `type`: Column type. The choices are `boolean`, `tinyint`, `smallint`, `integer`, `bigint`, `double`, `float`, `real`, `decimal`, `char`, `varchar(size)`, `longvarchar`, `date`, `time`, `timestamp`, `bu_date`, `bu_timestamp`, `blob`, and `clob`.
-  * `required`: Boolean. Set it to `true` if you want the column to be required.
-  * `size`: The size or length of the field for types that support it
-  * `scale`: Number of decimal places for use with decimal data type (size must also be specified)
-  * `default`: Default value.
-  * `primaryKey`: Boolean. Set it to `true` for primary keys.
-  * `autoIncrement`: Boolean. Set it to `true` for columns of type `integer` that need to take an auto-incremented value.
-  * `sequence`: Sequence name for databases using sequences for `autoIncrement` columns (for example, PostgreSQL and Oracle).
-  * `index`: Boolean. Set it to `true` if you want a simple index or to `unique` if you want a unique index to be created on the column.
-  * `foreignTable`: A table name, used to create a foreign key to another table.
-  * `foreignReference`: The name of the related column if a foreign key is defined via `foreignTable`.
-  * `onDelete`: Determines the action to trigger when a record in a related table is deleted. When set to `setnull`, the foreign key column is set to `null`. When set to `cascade`, the record is deleted. If the database engine doesn't support the set behavior, the ORM emulates it. This is relevant only for columns bearing a `foreignTable` and a `foreignReference`.
-  * `isCulture`: Boolean. Set it to `true` for culture columns in localized content tables (see Chapter 13).
+  * `type`: il tipo. Le scelte sono tra `boolean`, `tinyint`, `smallint`, `integer`, `bigint`, `double`, `float`, `real`, `decimal`, `char`, `varchar(size)`, `longvarchar`, `date`, `time`, `timestamp`, `bu_date`, `bu_timestamp`, `blob` e `clob`.
+  * `required`: Booleano. Impostare a `true` se si vuole che la colonna sia obbligatoria.
+  * `size`: La dimensione o la lunghezza del campo, per i tipi che la supportano.
+  * `scale`: Numero di cifre decimali, per il tipo `decimal` (occorre specificare anche `size`).
+  * `default`: Il valore predefinito.
+  * `primaryKey`: Booleano. Impostare a `true` per le chiavi primarie.
+  * `autoIncrement`: Booleano. Impostare a `true` per le colonne di tipo `integer` che devono avere un valore auto-incrementato.
+  * `sequence`: Nome della sequenza da usare per le colonne `autoIncrement` (per PostgreSQL e Oracle).
+  * `index`: Booleano. Impostare a `true` per un indice semplice o a `unique` per una chiave univoca sulla colonna.
+  * `foreignTable`: Un nome di tabella, usato per creare una chiave esterna.
+  * `foreignReference`: Il nome di una colonna correlata, se una chiave esterna è definita con `foreignTable`.
+  * `onDelete`: Determinea l'azione da eseguire quando un record viene cancellato. Se impostato a `setnull`, la colonna della chiave esterna viene posta a `null`. Se impostato a `cascade`, il record viene cancellato. Se il database non supporta questi comportamenti, l'ORM li emula. Questo è rilevante solo per colonne con `foreignTable` e `foreignReference`.
+  * `isCulture`: Booleano. Impostare a `true` per colonne che riportano la cultura nelle tabelle localizzate (vedere capitolo 13).
 
-### Foreign Keys
+### Chiavi esterne
 
-As an alternative to the `foreignTable` and `foreignReference` column attributes, you can add foreign keys under the `_foreignKeys:` key in a table. The schema in Listing 8-28 will create a foreign key on the `user_id` column, matching the `id` column in the `blog_user` table.
+Come alternativa agli attributi `foreignTable` e `foreignReference` delle colonne, si può usare la chiave `_foreignKeys:` in una tabella. Lo schema nel Listato 8-28 crea una chiave esterna per la colonna `user_id` verso la colonna `id` della tabella `blog_user`.
 
-Listing 8-28 - Foreign Key Alternative Syntax
+Listato 8-28 - Sintassi alternativa per le chiavi esterne
 
     [yml]
     propel:
@@ -800,23 +799,23 @@ Listing 8-28 - Foreign Key Alternative Syntax
             references:
               - { local: user_id, foreign: id }
 
-The alternative syntax is useful for multiple-reference foreign keys and to give foreign keys a name, as shown in Listing 8-29.
+La sintassi alternativa è utile per chiavi esterne multiple e per dare un nome alle chiavi esterne, come mostrato nel Listato 8-29.
 
-Listing 8-29 - Foreign Key Alternative Syntax Applied to Multiple Reference Foreign Key
+Listato 8-29 - Sintassi alternativa per le chiavi esterne applicata a chiavi esterne multiple
 
         _foreignKeys:
-          my_foreign_key:
+          nome_chiave:
             foreignTable:  db_user
             onDelete:      cascade
             references:
               - { local: user_id, foreign: id }
               - { local: post_id, foreign: id }
 
-### Indexes
+### Indici
 
-As an alternative to the `index` column attribute, you can add indexes under the `_indexes:` key in a table. If you want to define unique indexes, you must use the `_uniques:` header instead. For columns that require a size, because they are text columns, the size of the index is specified the same way as the length of the column using parentheses. Listing 8-30 shows the alternative syntax for indexes.
+Come alternativa all'attributo `index` di una colonna, si possono aggiungere indici sotto la chiave `_indexes:` in una tabella. Se si vogliono definire chiavi univoche, occorre invece usare `_uniques:`. Per colonne che richiedono una dimensione, perché sono colonne testuali, la dimensione dell'indice è specificata nello stesso modo della lunghezza delle colonne, usando le parentesi. Il Listato 8-30 mostra la sintassi alternativa per gli indici.
 
-Listing 8-30 - Indexes and Unique Indexes Alternative Syntax
+Listato 8-30 - Sintassi alternativa per indici e chiavi univoche
 
     [yml]
     propel:
@@ -825,38 +824,38 @@ Listing 8-30 - Indexes and Unique Indexes Alternative Syntax
         title:            varchar(50)
         created_at:
         _indexes:
-          my_index:       [title(10), user_id]
+          mio_indice:     [title(10), user_id]
         _uniques:
-          my_other_index: [created_at]
+          mio_indice_2:   [created_at]
 
-The alternative syntax is useful only for indexes built on more than one column.
+La sintassi alternativa è utile solo per indici su più colonne.
 
-### Empty Columns
+### Colonne vuote
 
-When meeting a column with no value, symfony will do some magic and add a value of its own. See Listing 8-31 for the details added to empty columns.
+Quando incontra una colonna senza valori, symfony fa alcune magie per aggiungere i suoi valori. Si veda il Listato 8-31 per i dettagli aggiunti alle colonne vuote.
 
-Listing 8-31 - Column Details Deduced from the Column Name
+Listato 8-31 - Dettagli delle colonne dedotti dal nome della colonna
 
-    // Empty columns named id are considered primary keys
+    // Colonne vuote chiamate "id" sono considerate chiavi primarie
     id:         { type: integer, required: true, primaryKey: true, autoIncrement: true }
 
-    // Empty columns named XXX_id are considered foreign keys
+    // Colonne vuote chiamate "XXX_id" sono considerate chiavi esterne
     foobar_id:  { type: integer, foreignTable: db_foobar, foreignReference: id }
 
-    // Empty columns named created_at, updated at, created_on and updated_on
-    // are considered dates and automatically take the timestamp type
+    // Colonne vuote chiamate "created_at", "updated at", "created_on" e "updated_on"
+    // sono considerate date e diventano di tipo timestamp
     created_at: { type: timestamp }
     updated_at: { type: timestamp }
 
-For foreign keys, symfony will look for a table having the same `phpName` as the beginning of the column name, and if one is found, it will take this table name as the `foreignTable`.
+Per le chiavi esterne, symfony cercherà una tabella con lo stesso `phpName` dell'inizio del nome della colonna e, se ne troverà uno, userà il suo nome come `foreignTable`.
 
-### I18n Tables
+### Tabelle I18n
 
-Symfony supports content internationalization in related tables. This means that when you have content subject to internationalization, it is stored in two separate tables: one with the invariable columns and another with the internationalized columns.
+Symfony supporta l'internazionalizzazione dei contenuti tramite tabelle dedicate. Questo significa che quando si ha un contenuto da internazionalizzare, viene memorizzato in due tabelle separate: una per le colonne che non cambiano e una per le colonne da internazionalizzare.
 
-In a `schema.yml` file, all that is implied when you name a table `foobar_i18n`. For instance, the schema shown in Listing 8-32 will be automatically completed with columns and table attributes to make the internationalized content mechanism work. Internally, symfony will understand it as if it were written like Listing 8-33. Chapter 13 will tell you more about i18n.
+In un file `schema.yml`, tutto è implicito quando si dà il nome `pippo_i18n` a una tabella. Per esempio, lo schema mostrato nel Listato 8-32 verrà automaticamente completato con colonne e attributi per far funzionare il meccanismo di internazionalizzazione. Internamente, symfony lo interpreterà come se fosse scritto come nel Listato 8-33. Il capitolo 13 contiene maggiori informazioni su i18n.
 
-Listing 8-32 - Implied i18n Mechanism
+Listato 8-32 - Meccanismo i18n implicito
 
     [yml]
     propel:
@@ -867,7 +866,7 @@ Listing 8-32 - Implied i18n Mechanism
       db_group_i18n:
         name:        varchar(50)
 
-Listing 8-33 - Explicit i18n Mechanism
+Listato 8-33 - Meccanismo i18n esplicito
 
     [yml]
     propel:
@@ -881,11 +880,11 @@ Listing 8-33 - Explicit i18n Mechanism
         culture:  { isCulture: true, type: varchar(7), required: true,primaryKey: true }
         name:     varchar(50)
 
-### Behaviors
+### Comportamenti
 
-Behaviors are model modifiers provided by plug-ins that add new capabilities to your Propel classes. Chapter 17 explains more about behaviors. You can define behaviors right in the schema, by listing them for each table, together with their parameters, under the `_behaviors` key. Listing 8-34 gives an example by extending the `BlogArticle` class with the `paranoid` behavior.
+I comportamenti sono modificatori dei modelli forniti da plugin, che aggiungono nuove capacità alle classi di Propel. Il capitolo 17 parla più approfonditamente dei comportamenti. I comportamenti si possono definire nello schema, elencandoli per ciascuna tabella, insieme con i loro parametri, sotto la chiave `_behaviors`. Il Listato 8-34 fornisce un esempio estendendo la classe `BlogArticle` con il comportamento `paranoid`.
 
-Listing 8-34 - Behaviors Declaration
+Listato 8-34 - Dichiarazione dei comportamenti
 
     [yml]
     propel:
@@ -894,13 +893,13 @@ Listing 8-34 - Behaviors Declaration
         _behaviors:
           paranoid:     { column: deleted_at }
 
-### Beyond the schema.yml: The schema.xml
+### Oltre lo schema.yml: lo schema.xml
 
-As a matter of fact, the `schema.yml` format is internal to symfony. When you call a propel- command, symfony actually translates this file into a `generated-schema.xml` file, which is the type of file expected by Propel to actually perform tasks on the model.
+Di fatto, il formato `schema.yml` è interno a symfony. Quando si richiama un comando di Propel, symfony traduce tale file in un file `generated-schema.xml`, che è il tipo di file che Propel si aspetta per eseguire effettivamente ciò che deve fare sul modello.
 
-The `schema.xml` file contains the same information as its YAML equivalent. For example, Listing 8-3 is converted to the XML file shown in Listing 8-35.
+Il file `schema.xml` contiene le stesse informazioni del suo equivalente YAML. Per esempio, il Listato 8-3 viene convertito nel file XML mostrato nel Listato 8-35.
 
-Listing 8-35 - Sample `schema.xml`, Corresponding to Listing 8-3
+Listato 8-35 - Esempio di `schema.xml`, corrispondente al Listato 8-3
 
     [xml]
     <?xml version="1.0" encoding="UTF-8"?>
@@ -923,87 +922,87 @@ Listing 8-35 - Sample `schema.xml`, Corresponding to Listing 8-3
         </table>
      </database>
 
-The description of the `schema.xml` format can be found in the documentation and the "Getting Started" sections of the Propel project [website](http://propel.phpdb.org/docs/user_guide/chapters/appendices/AppendixB-SchemaReference.html).
+La descrizione del formato `schema.xml` si trova nella sezione "Getting Started" del [sito di Propel](http://www.propelorm.org/wiki/Documentation/1.4/Schema-Reference).
 
-The YAML format was designed to keep the schemas simple to read and write, but the trade-off is that the most complex schemas can't be described with a `schema.yml` file. On the other hand, the XML format allows for full schema description, whatever its complexity, and includes database vendor-specific settings, table inheritance, and so on.
+Il formato YAML è stato disegnato per mantenere gli schemi semplici da leggere e da scrivere, ma il prezzo da pagare è la difficoltà di descrivere schemi più complessi con un file `schema.yml`. D'altro canto, il formato XML consente una descrizione completa dello schema, qualunque complessità esso abbia, e include impostazioni specifiche per i database, ereditarietà delle tabelle e così via.
 
-Symfony actually understands schemas written in XML format. So if your schema is too complex for the YAML syntax, if you have an existing XML schema, or if you are already familiar with the Propel XML syntax, you don't have to switch to the symfony YAML syntax. Place your `schema.xml` in the project `config/` directory, build the model, and there you go.
+Symfony comprende anche gli schemi scritti in formato XML. Quindi, se si ha uno schema troppo complesso per la sintassi YAML o se si ha uno schema XML già esistente, non è necessario passare alla sintassi YAML. Basta mettere il proprio `schema.xml` nella cartella `config/` del progetto directory e costruire il modello.
 
 >**SIDEBAR**
 >Propel in symfony
 >
->All the details given in this chapter are not specific to symfony, but rather to Propel. Propel is the preferred object/relational abstraction layer for symfony, but you can choose an alternative one. However, symfony works more seamlessly with Propel, for the following reasons:
+>Tutti i dettagli dati in questo capitolo non sono specifici di symfony, ma piuttosto di Propel. Si può scegliere un livello di astrazione di ogetti/relazioni, ma symfony funziona molto bene con Propel, per le seguenti ragioni:
 >
->All the object data model classes and the `Criteria` class are autoloading classes. As soon as you use them, symfony will include the right files, and you don't need to manually add the file inclusion statements. In symfony, Propel doesn't need to be launched nor initialized. When an object uses Propel, the library initiates by itself. Some symfony helpers use Propel objects as parameters to achieve high-level tasks (such as pagination or filtering). Propel objects allow rapid prototyping and generation of a backend for your application (Chapter 14 provides more details). The schema is faster to write through the `schema.yml` file.
+>Tutti gli oggetti delle classi del modello e le classi `Criteria` si caricano automaticamente. Non appena le si usa, symfony includerà i file giusti e non si avrà bisogno di istruzioni di inclusione. In symfony, Propel non ha bisogno di essere lanciato né inizializzato. Quando un oggetto usa Propel, la libreria si inizializza da sé. Alcuni helper di symfony usano gli oggetti di Propel per compiti ad alto livello (come paginazione o filtri). Gli oggetti di Propel consentono una prototipazione rapida e la generazione di un backend per la propria applicazione (il capitolo 14 fornisce maggiori dettagli in merito). Lo schema è più veloce da scrivere con il file `schema.yml`.
 >
->And, as Propel is independent of the database used, so is symfony.
+>Infine, Propel è indipendente dal database usato, così come lo è symfony.
 
-Don't Create the Model Twice
-----------------------------
+Non creare il modello due volte
+-------------------------------
 
-The trade-off of using an ORM is that you must define the data structure twice: once for the database, and once for the object model. Fortunately, symfony offers command-line tools to generate one based on the other, so you can avoid duplicate work.
+Lo svantaggio nell'utilizzo di un ORM è che bisogna definire la struttura dati due volte: una per il database e una per il modello a oggetti. Per fortuna, symfony fornisce degli strumenti a riga di comando per generare l'uno basato sull'altro, in modo da evitare la duplicazione del lavoro.
 
-### Building a SQL Database Structure Based on an Existing Schema
+### Creare l'SQL della struttura di un database basandosi su uno schema esistente
 
-If you start your application by writing the `schema.yml` file, symfony can generate a SQL query that creates the tables directly from the YAML data model. To use the query, go to your root project directory and type this:
+Se si inizia l'applicazione scrivendo il file `schema.yml`, symfony può generare una query SQL che crea le tabelle direttamente dal modello YAML dei dati. Per generare la query, andare nella cartella radice del progetto e digitare:
 
     $ php symfony propel:build-sql
 
-A `lib.model.schema.sql` file will be created in `myproject/data/sql/`. Note that the generated SQL code will be optimized for the database system defined in the `phptype` parameter of the `propel.ini` file.
+Verrà creato un file `lib.model.schema.sql` in `mioprogetto/data/sql/`. Notare che il codice SQL generato sarà ottimizzato per il sistema di database definito nel parametro `phptype` o nel file `propel.ini`.
 
-You can use the `schema.sql` file directly to build the tables. For instance, in MySQL, type this:
+Si può usare il file `lib.model.schema.sql` direttamente per costruire le tabelle. Ad esempio, in MySQL, digitare:
 
     $ mysqladmin -u root -p create blog
     $ mysql -u root -p blog < data/sql/lib.model.schema.sql
 
-The generated SQL is also helpful to rebuild the database in another environment, or to change to another DBMS. If the connection settings are properly defined in your `propel.ini`, you can even use the `php symfony propel:insert-sql` command to do this automatically.
+Il codice SQL generato è utile anche per ricostruire il database in un altro ambiente o per passare a un altro database. Se le impostazioni di connessioni sono definite correttamente in `propel.ini`, si può anche usare il comando `php symfony propel:insert-sql` per farlo automaticamente.
 
 >**TIP**
->The command line also offers a task to populate your database with data based on a text file. See Chapter 16 for more information about the `propel:data-load` task and the YAML fixture files.
+>La riga di comando offre anche un task per popolare il database con i dati caricati da un file di testo. Vedere il capitolo 16 per maggiori informazioni sul task `propel:data-load` e i file delle fixture in YAML.
 
-### Generating a YAML Data Model from an Existing Database
+### Generare un modello dei dati YAML da un database esistente
 
-Symfony can use Propel to generate a `schema.yml` file from an existing database, thanks to introspection (the capability of databases to determine the structure of the tables on which they are operating). This can be particularly useful when you do reverse-engineering, or if you prefer working on the database before working on the object model.
+Symfony può usare Propel per generare un file `schema.yml` da un database esistente, grazie alla introspezione (la capacità dei database di determinare la struttura delle tabelle sulle quali stanno operando). Questo può essere particolarmente utile quando si fa reverse-engineering, oppure quando si preferisce lavorare sul database prima di lavorare sul modello a oggetti.
 
-In order to do this, you need to make sure that the project `databases.yml` file points to the correct database and contains all connection settings, and then call the `propel:build-schema` command:
+Per fare ciò, è necessario assicurarsi che il file `databases.yml` del progetto punti al database corretto e contenga tutte le informazioni per la connessione. Quindi lanciare il comando `propel:build-schema`:
 
     $ php symfony propel:build-schema
 
-A brand-new `schema.yml` file built from your database structure is generated in the `config/` directory. You can build your model based on this schema.
+Dalla struttura del database viene generato un nuovo file `schema.yml` nella cartella `config/`. Si può costruire il modello basato su questo schema.
 
-The schema-generation command is quite powerful and can add a lot of database-dependent information to your schema. As the YAML format doesn't handle this kind of vendor information, you need to generate an XML schema to take advantage of it. You can do this simply by adding an `xml` argument to the `build-schema` task:
+Il comando di generazione dello schema è potente e può aggiungere allo schema molte informazioni dipendenti dal database. Poiché il formato YAML non gestisce questo tipo di informazioni, occorre generare uno schema XML per poterle sfruttare. Lo si può fare semplicemente aggiungendo un parametro `xml` al task `build-schema`:
 
     $ php symfony propel:build-schema --xml
 
-Instead of generating a `schema.yml` file, this will create a `schema.xml` file fully compatible with Propel, containing all the vendor information. But be aware that generated XML schemas tend to be quite verbose and difficult to read.
+Invece di generare un file `schema.yml`, verrà creato un file `schema.xml` pienamente compatibile con Propel, contenente tutte le informazioni specifiche del database. Si faccia però attenzione, perché gli schemi XML tendono a essere molto prolissi e difficili da leggere.
 
 >**SIDEBAR**
->The `propel.ini` Configuration
+>La configurazione `propel.ini`
 >
->This file contains other settings used to configure the Propel generator to make generated model classes compatible with symfony. Most settings are internal and of no interest to the user, apart from a few:
+>Questo file contiene altre impostazioni usate per configurare il generatore di Propel per rendere le classi del modello generate maggiormente compatibili con symfony. La maggior parte delle impostazioni sono di uso interno e senza interesse per l'utente, tranne alcune:
 >
->      // Base classes are autoloaded in symfony
->      // Set this to true to use include_once statements instead
->      // (Small negative impact on performance)
+>      // Le classi Base sono autocaricate in symfony
+>      // Impostare a true per usare invece include_once
+>      // (Piccolo impatto negativo sulle prestazioni)
 >      propel.builder.addIncludes = false
 >
->      // Generated classes are not commented by default
->      // Set this to true to add comments to Base classes
->      // (Small negative impact on performance)
+>      // Le classi generate non sono commentate
+>      // Impostare a true per aggiungere i commenti alle classi Base
+>      // (Piccolo impatto negativo sulle prestazioni)
 >      propel.builder.addComments = false
 >
->      // Behaviors are not handled by default
->      // Set this to true to be able to handle them
+>      // I comportamenti non sono gestiti
+>      // Impostare a true per poterli gestire
 >      propel.builder.AddBehaviors = false
 >
 >
->After you make a modification to the `propel.ini` settings, don't forget to rebuild the model so the changes will take effect.
+>Dopo una modifica al file `propel.ini`, non dimenticare di ricostruire il modello, in modo che i cambiamenti abbiano effetto.
 
-Summary
--------
+Riepilogo
+---------
 
-Symfony uses Propel as the ORM and PHP Data Objects as the database abstraction layer. It means that you must first describe the relational schema of your database in YAML before generating the object model classes. Then, at runtime, use the methods of the object and peer classes to retrieve information about a record or a set of records. You can override them and extend the model easily by adding methods to the custom classes. The connection settings are defined in a `databases.yml` file, which can support more than one connection. And the command line contains special tasks to avoid duplicate structure definition.
+Symfony usa Propel come ORM e gli oggetti dei dati di PHP per il livello di astrazione del database. Ciò significa che è necessario prima descrivere lo schema relazionale del database in YAML prima di generare le classi del modello a oggetti. Poi, in fase di runtime, utilizzare i metodi dell'oggetto e le classi peer per recuperare informazioni su un record o un insieme di record. È possibile sovrascrivere ed estendere facilmente il modello aggiungendo metodi alle classi personalizzate. Le impostazioni di connessione sono definite in un file `databases.yml`, che può supportare più di una connessione. E la linea di comando contiene dei task speciali per evitare di duplicare la definizione della struttura. 
 
-The model layer is the most complex of the symfony framework. One reason for this complexity is that data manipulation is an intricate matter. The related security issues are crucial for a website and should not be ignored. Another reason is that symfony is more suited for middle- to large-scale applications in an enterprise context. In such applications, the automations provided by the symfony model really represent a gain of time, worth the investment in learning its internals.
+Il livello del modello è il più complesso del framework symfony. Una delle ragioni di questa complessità è che la manipolazione dei dati è una questione intricata. I problemi di sicurezza correlati sono fondamentali per un sito web e non devono essere ignorati. Un'altra ragione è che symfony è più adatto ad applicazioni di medio-grandi dimensioni in contesto enterprise. In tali applicazioni, le automazioni fornite dal modello di symfony possono davvero rappresentare un guadagno di tempo che vale l'investimento per apprendere il suo funzionamento. 
 
-So don't hesitate to spend some time testing the model objects and methods to fully understand them. The solidity and scalability of your applications will be a great reward.
+Quindi non esitate nel dedicare un periodo di prova al modello a oggetti e ai metodi, per comprenderli pienamente. La solidità e la scalabilità delle applicazioni saranno la ricompensa.
diff --git a/reference/it/10-Routing.markdown b/reference/it/10-Routing.markdown
index af4ad4f..a8c7551 100644
--- a/reference/it/10-Routing.markdown
+++ b/reference/it/10-Routing.markdown
@@ -248,7 +248,7 @@ metodo è chiamato con i parametri della rotta scansionata come parametro.
 *Predefinito*: none
 
 L'opzione `method_for_query` definisce il metodo da chiamare sul modello per
-recuperare l'oggetto (o gli oggetti) associati con la richiesta corrente. L'ggetto della richiesta
+recuperare l'oggetto (o gli oggetti) associati con la richiesta corrente. L'oggetto della richiesta
 corrente è passato come parametro.
 
 Se l'opzione non è assegnata, la richiesta è solo "eseguita" con il metodo
diff --git a/tutorial/it/upgrade.markdown b/tutorial/it/upgrade.markdown
index 220de6c..e926dd1 100644
--- a/tutorial/it/upgrade.markdown
+++ b/tutorial/it/upgrade.markdown
@@ -229,13 +229,13 @@ escape solamente i caratteri di barra `\`, le virgolette `'` e `"` e gli "a capo
 Integrazione con Doctrine
 -------------------------
 
-### Versione Richiesta di Doctrine
+### Versione richiesta di Doctrine
 
 Gli external verso Doctrine sono stati aggiornati all'ultima versione di
 Doctrine 1.2. Si possono avere informazioni sulle novità di Doctrine 1.2 
 [qui](http://www.doctrine-project.org/upgrade/1_2).
 
-### Cancellazione nell'Admin Generator
+### Cancellazione nell'admin generator
 
 La cancellazione multipla nell'admin generator è stata modificata per
 scorrere le righe ed eseguire il metodo `delete()` su ciascuna di esse
@@ -243,7 +243,7 @@ singolarmente, piuttosto che eseguire una singola query DQL per cancellarle
 tutte. Questo per fare in modo che siano invocati gli eventi per la
 cancellazione di ogni singola riga.
 
-### Sovrascrittura dello Schema Doctrine dei Plugin
+### Sovrascrittura dello schema doctrine dei plugin
 
 Si può sovrascrivere il modello incluso in uno schema YAML di un plugin,
 semplicemente definendo lo stesso modello nel proprio schema locale.
diff --git a/tutorial/it/whats-new.markdown b/tutorial/it/whats-new.markdown
index d216ffd..901aaf5 100644
--- a/tutorial/it/whats-new.markdown
+++ b/tutorial/it/whats-new.markdown
@@ -84,7 +84,7 @@ I primi tre sostituiscono i widget `sfWidgetFormI18nSelectLanguage`,
 `sfWidgetFormI18nSelectCurrency` e `sfWidgetFormI18nSelectCountry`, che ora
 sono deprecati.
 
-### Interfaccia Fluida
+### Interfaccia fluida
 
 I widget ora implementano un'interfaccia fluida per i seguenti metodi:
 
@@ -151,7 +151,7 @@ Sono stati aggiunti i seguenti validatori:
 
  * `sfValidatorI18nChoiceTimezone`
 
-### Messaggi di Errore Predefiniti
+### Messaggi di errore predefiniti
 
 Si possono ora definire dei messaggi di errore predefiniti in modo globale,
 usando il metodo `sfForm::setDefaultMessage()`:
@@ -180,7 +180,7 @@ determinato nel modo seguente:
  * Se non definito, usa il messaggio predefinito dal validatore stesso
    (quando il messaggio è stato aggiunto col metodo `addMessage()`).
 
-### Interfaccia Fluida
+### Interfaccia fluida
 
 I validatori ora implementano un'interfaccia fluida per i seguenti metodi:
 
@@ -292,7 +292,7 @@ nel suo metodo `configure()`:
 Richiamando `disableLocalCSRFProtection()`, la protezione CSRF sarà
 disabilitata, anche se si passa una stringa segreta CSRF all'istanza del form.
 
-### Interfaccia Fluida
+### Interfaccia fluida
 
 Alcuni metodi di `sfForm` ora implementano un'interfaccia fluida:
 `addCSRFProtection()`, `setValidators()`, `setValidator()`, `setValidatorSchema()`,
@@ -315,7 +315,7 @@ eseguire `symfony cc` dopo l'aggiunta di una nuova classe al progetto.
 Test
 ----
 
-### Accelerazione dei Test
+### Accelerazione dei test
 
 Quando si hanno molti test, lanciarli tutti dopo ogni modifica può portar via
 molto tempo, specialmente quando alcuni test falliscono. Questo perché
@@ -335,7 +335,7 @@ passeranno e saranno quindi rimossi dalle esecuzioni successive. Quando
 tutti i test passano di nuovo, tutti i test vengono eseguiti... si può
 quindi ripetere a piacere.
 
-### Test Funzionali
+### Test funzionali
 
 Quando una richiesta genera un'eccezione, il metodo `debug()` del tester della
 risposta ora manda in output una rappresentazione testuale leggibile
@@ -354,7 +354,7 @@ Inoltre sostitusce il metodo `contains()`, meno potente:
       matches('!/Ho \d+ mele/i')->  // si possono usare anche i modificatori
     end();
 
-### Output XML Compatibile con JUnit
+### Output XML compatibile con JUnit
 
 I task dei test ora possono inviare in output un file XML compatibile con
 JUnit, usando l'opzione `--xml`:
@@ -369,7 +369,7 @@ dei fallimenti:
 
     $ php symfony test:all -t
 
-### Colorazione dell'Output di Lime
+### Colorazione dell'output di Lime
 
 Da symfony 1.3/1.4, lime si comporta bene riguardo alla colorazione. Questo vuol
 dire che si può omettere quasi sempre il secondo parametro del costruttore
@@ -623,12 +623,12 @@ Il task `generate:app` ora cerca uno scheletro di cartelle nella cartella
 `data/skeleton/app` del progetto, prima di usare lo scheletro predefinito
 distribuito con symfony.
 
-### Invio di Email da un Task
+### Invio di email da un task
 
 Si può ora inviare facilmente una email da un task, usando il metodo
 `getMailer()`.
 
-### Usare il Routing in un Task
+### Usare il routing in un task
 
 Si può ora recuperare facilmente l'oggetto routing da un task, usando
 il metodo `getRouting()`.
@@ -642,7 +642,7 @@ Quando viene lanciata un'eccezione durante un autoload, symfony ora la
 cattura e mostra l'errore all'utente. Questo dovrebbe risolvere il problema
 delle pagine bianche.
 
-### Web Debug Toolbar
+### Web debug toolbar
 
 Se possibile, la web debug toolbar ora viene mostrata anche sulle pagine
 delle eccezioni, nell'ambiente di sviluppo.
@@ -730,7 +730,7 @@ in `ProjectConfiguration`:
 Routing
 -------
 
-### Richieste Predefinite
+### Richieste predefinite
 
 La richiesta predefinita `\d+` è ora applicata a `sfObjectRouteCollection`
 solo quando l'opzione `column` è il predefinito `id`. Questo vuol dire
@@ -752,7 +752,7 @@ Consente di registrare dei parametri predefiniti per ogni rotta generata:
 CLI
 ---
 
-### Colorazione dell'Otput 
+### Colorazione dell'output 
 
 Symfony prova a indovinare se la console supporta i colori, quando si usano
 gli strumenti della CLI. Ma a volte symfony si sbaglia; ad esempio quando si
@@ -864,7 +864,7 @@ Doctrine è stato aggiornato alla versione 1.2. Si visiti il sito di Doctrine
 per ulteriori informazioni sul suo aggiornamento
 (http://www.doctrine-project.org/documentation/1_2/en).
 
-### Generazione delle Classi dei Form
+### Generazione delle classi dei form
 
 È ora possibile specificare delle opzioni aggiuntive per symfony nei file YAML
 degli schema di Doctrine. Abbiamo aggiunto alcune opzioni per disabilitare la
@@ -888,13 +888,13 @@ nel modo seguente:
           type: integer
           primary: true
 
-### Ereditarietà delle Classi dei Form
+### Ereditarietà delle classi dei form
 
 Quando si generano form dai modelli, i modelli contengono ereditarietà.
 Le classi figlie generate rispetteranno l'ereditarietà e genereranno
 form che seguono la stessa struttura di ereditarietà.
 
-### Nuovi Task
+### Nuovi task
 
 Abbiamo introdotto alcuni nuovi task che aiutano nello sviluppo con Doctrine.
 
@@ -952,7 +952,7 @@ equivale a eseguire questi comandi:
     $ php symfony doctrine:insert-sql
     $ php symfony doctrine:data-load
 
-#### Altri Build
+#### Altri build
 
 Il nuovo task `doctrine:build` consente di specificare esattamente cosa si
 vuole che symfony e Doctrine costruiscano. Questo task replica la
@@ -1009,7 +1009,7 @@ file in TextMate.
 Questo nuovo task genererà automaticamente delle classi per una completa
 migrazione, in base agli schemi vecchi e a quelli nuovi.
 
-### Setter e Getter di Date
+### Setter e getter di date
 
 Abbiamo aggiunto nuovi metodi per recuperare i valori di date o timestamp
 di Doctrine come istanze di oggetti DateTime di PHP.
@@ -1038,7 +1038,7 @@ si può trarre vantaggio dalla nuova opzione `dry-run`.
 
     $ php symfony doctrine:migrate --dry-run
 
-### Output dei Task DQL come Tabelle di Dati
+### Output dei task DQL come tabelle di dati
 
 Quando si eseguiva il comando `doctrine:dql`, questo mostrava i dati solo
 come YAML. Abbiamo aggiunto una nuova opzione `--table`. Tale opzione consente
@@ -1181,7 +1181,7 @@ L'uso di una diversa versione di Doctrine è facile, basta impostare
       sfConfig::set('sf_doctrine_dir', '/path/to/doctrine/lib');
     }
 
-Web Debug Toolbar
+Web debug toolbar
 -----------------
 
 ### `sfWebDebugPanel::setStatus()`
@@ -1207,7 +1207,7 @@ all'opzione `request_parameters`:
 Partial
 -------
 
-### Miglioramenti agli Slot
+### Miglioramenti agli slot
 
 Gli helper `get_slot()` e `include_slot()` ora accettano un secondo
 parametro per specificare il contenuto predefinito dello slot, da
@@ -1254,7 +1254,7 @@ Due parametri sono disponibili in `factories.yml`:
     In pratica, dice se la cache della pagina debba essere dipendente
     dal nome dell'host.
 
-### Più Cache
+### Più cache
 
 Il gestore della cache delle viste non rifiuta più di mettere in cache
 in presenza di valori in `$_GET` o `$_POST`.La logica ora conferma solo