| [PATCH] Doc-it: add Suggestions chapter of Usage (plus some fixes) |
[ Thread Index |
Date Index
| More lilynet.net/translations Archives
]
- Subject: [PATCH] Doc-it: add Suggestions chapter of Usage (plus some fixes)
- From: Federico Bruni <fedelogy@xxxxxxxxx>
- Date: Sat, 23 Apr 2011 16:55:09 +0200
---
Documentation/it/usage.tely | 3 +-
Documentation/it/usage/running.itely | 98 +++---
Documentation/it/usage/suggestions.itely | 606 ++++++++++++++++++++++++++++++
Documentation/it/usage/updating.itely | 33 +-
4 files changed, 672 insertions(+), 68 deletions(-)
create mode 100644 Documentation/it/usage/suggestions.itely
diff --git a/Documentation/it/usage.tely b/Documentation/it/usage.tely
index 06b2df9..08e4169 100644
--- a/Documentation/it/usage.tely
+++ b/Documentation/it/usage.tely
@@ -14,6 +14,7 @@
@afourpaper
@c Translators: Federico Bruni
+@c Translation checkers: Luca Rossetto Casel
@macro manualIntro
Questo manuale spiega come eseguire i programmi distribuiti con
@@ -53,7 +54,7 @@ Copyright @copyright{} 1999--2011 degli autori.
* Aggiornare i file con convert-ly:: Aggiornare i file di input.
* lilypond-book:: Integrare testo e musica.
* Programmi esterni:: Combinare LilyPond con altri programmi.
-* Suggerimenti su come scrivere i file:: Migliori pratiche ed efficace soluzione degli errori.
+* Consigli su come scrivere i file:: Migliori pratiche ed efficace soluzione degli errori.
Appendici
diff --git a/Documentation/it/usage/running.itely b/Documentation/it/usage/running.itely
index 868d364..e044867 100644
--- a/Documentation/it/usage/running.itely
+++ b/Documentation/it/usage/running.itely
@@ -1,7 +1,7 @@
@c -*- coding: utf-8; mode: texinfo; documentlanguage: it -*-
@ignore
- Translation of GIT committish: 7ba0a22641cb0c7f5949d66a06d1e2e1fd0b3033
+ Translation of GIT committish: cff226053d927e433473697fe743bdfd721d2607
When revising a translation, copy the HEAD committish of the
version that you are working on. For details, see the Contributors'
@@ -40,11 +40,11 @@ diverso per scrivere i file lilypond, leggi la documentazione di quel programma.
@translationof Command-line usage
Questa sezione contiene informazioni aggiuntive sull'uso di LilyPond da linea
-di comando. Questo può essere utile per passare al programma opzioni ulteriori.
+di comando. Questo può essere utile per assegnare opzioni aggiuntive al programma.
Inoltre, ci sono alcuni programmi complementari di @q{aiuto} (come
@code{midi2ly}) che funzionano solo da linea di comando.
-Con @q{linea di comando} intendiamo la linea di comando del sistema operativo.
+Con @q{linea di comando} si intende la linea di comando del sistema operativo.
Gli utenti Windows avranno più familiarità con i termini @q{shell DOS} o
@q{shell dei comandi}. Gli utenti MacOS@tie{}X avranno più familiarità con i termini
@q{terminale} o @q{console}. Una configurazione ulteriore è necessaria
@@ -58,14 +58,14 @@ questo argomento se non si conosce la linea di comando.
* Invocare lilypond::
* Opzioni della linea di comando per lilypond::
* Variabili d'ambiente::
-* LilyPond in chroot jail::
+* LilyPond in una gabbia chroot::
@end menu
@node Invocare lilypond
@unnumberedsubsec Invocare @command{lilypond}
@translationof Invoking lilypond
-L'eseguibile @command{lilypond} può essere chiamato dalla linea di comando
+L'eseguibile @command{lilypond} può essere lanciato dalla linea di comando
nel seguente modo.
@example
@@ -79,9 +79,9 @@ trattino (@code{-}) al posto di @var{file}.
Quando @file{file.ly} viene elaborato, lilypond creerà @file{file.ps}
e @file{file.pdf} come output. Possono essere specificati molti file;
-ognuno di essi sarà elaborati in modo indipendente. @footnote{Lo status di
-GUILE non viene resettato dopo l'elaborazione di un file @code{.ly}, quindi
-fare attenzione a non cambiare alcun valore predefinito dall'interno di Scheme.}
+ognuno di essi sarà elaborato in modo indipendente. @footnote{Lo status di
+GUILE non viene resettato dopo l'elaborazione di un file @code{.ly}:
+attenzione a non cambiare alcun valore predefinito dall'interno di Scheme.}
Se @file{file.ly} contiene più di un blocco @code{\book}, allora tutte le altre
partiture verranno salvate in file numerati, a partire da @file{file-1.pdf}. Inoltre,
@@ -139,10 +139,10 @@ Sono contemplate le seguenti opzioni:
@item -e,--evaluate=@var{espressione}
Valuta l'@var{espressione} di Scheme prima di analizzare qualsiasi file @file{.ly}.
-Si possono specificare varie opzioni @code{-e}; verranno valutate in modo
+Si possono specificare varie opzioni @code{-e}; saranno analizzate in modo
sequenziale.
-L'espressione sarà valutata nel modulo @code{guile-user}, dunque se vuoi
+L'espressione sarà analizzata nel modulo @code{guile-user}, dunque se vuoi
usare delle definizioni in @var{espressione}, usa
@example
@@ -203,7 +203,7 @@ Questa opzione imposta la dimensione predefinita del foglio,
@end example
@noindent
-Si noti che la stringa deve essere compresa tra virgolette precedute dal
+Nota che la stringa deve essere compresa tra virgolette precedute dal
segno di escape ( @code{\"} ).
@c Match " in previous line to help context-sensitive editors
@@ -226,7 +226,7 @@ scempio, ad esempio
@end verbatim
@end quotation
-L'opzione @code{-dsafe} funziona valutando le espressioni Scheme presenti nell'input
+L'opzione @code{-dsafe} serve a valutare le espressioni Scheme presenti nell'input
in uno speciale modulo di sicurezza. Questo modulo di sicurezza è derivato dal
modulo GUILE @file{safe-r5rs}, ma aggiunge alcune funzioni del
LilyPond API. Queste funzioni sono elencate in @file{scm/safe-lily.scm}.
@@ -325,7 +325,7 @@ Estrae un campo dell'intestazione nel file @file{NOME.@var{CAMPO}}.
@item --include, -I=@var{directory}
Aggiunge @var{directory} al percorso di ricerca per i file di input.
-� possibile assegnare più di un'opzione -I. La ricerca inizierà nella prima
+� possibile assegnare più opzioni -I. La ricerca inizierà nella prima
directory definita, e se il file da includere non viene trovato
la ricerca continuerà nelle directory seguenti.
@@ -338,8 +338,8 @@ Imposta il file di inizializzazione su @var{file} (predefinito: @file{init.ly}).
@item -o,--output=@var{FILE} or @var{CARTELLA}
Imposta il file di output predefinito @var{FILE} oppure, se una cartella con
quel nome esiste già , dirige l'output in @var{CARTELLA}, prendendo il nome
-del file dal file di input. Il suffisso appropriato verrÃ
-aggiunto (ad esempio @code{.pdf} per il pdf) in entrambi i casi.
+del file dal file di input. In entrambi i casi verrà aggiunto il suffisso
+appropriato (ad esempio @code{.pdf} per il pdf).
@cindex PostScript
@@ -378,7 +378,7 @@ garantisce che non sia possibile (almeno in teoria) uscire dalla gabbia. Si not
che perché @code{--jail} funzioni @command{lilypond} deve essere eseguito come root;
di solito questo si fa in modo sicuro col comando @command{sudo}.
-Configurare una gabbia è una questione leggermente delicata, perché bisogna essere
+Configurare una gabbia è una questione un po' delicata, perché bisogna essere
sicuri che LilyPond possa trovare tutto quello di cui ha bisogno per compilare il
sorgente @emph{dentro la gabbia}. Una configurazione tipica comprende i seguenti
elementi:
@@ -390,8 +390,8 @@ montato con opzioni di sicurezza come @code{noexec}, @code{nodev}, e
@code{nosuid}. In questo modo è impossibile lanciare degli eseguibili o
scrivere su un dispositivo direttamente da LilyPond. Se non si vuole creare
una partizione separata, si può creare un file di dimensioni ragionevoli e usarlo
-per montare un dispositivo di loop. Un filesystem separato garantisce anche che
-LilyPond non possa scrivere su uno spazio maggiore di quanto permesso.
+per montare un dispositivo di loop. Un filesystem separato garantisce inoltre
+che LilyPond non possa scrivere su uno spazio maggiore di quanto permesso.
@item Impostare un altro utente
Per eseguire LilyPond in una gabbia si dovrebbe usare un altro utente e gruppo
@@ -416,7 +416,7 @@ non richieda tale programma. Come è già stato detto, deve essere eseguito
con privilegi di superutente (che ovviamente perderà immediatamente),
possibilmente con l'uso di @command{sudo}. Ã? una buona idea limitare il
numero di secondi di tempo della CPU che LilyPond può usare (ad esempio con @command{ulimit
--t}), e, se il tuo sistema operativo lo supporta, la quantità di memoria che
+-t}), e, se il sistema operativo lo permette, la quantità di memoria che
può essere allocata.
@end table
@@ -429,7 +429,7 @@ Aumenta la prolissità : mostra i percorsi completi di tutti i file letti, e dÃ
informazioni sui tempi.
@item -w,--warranty
-Mostra la garanzia con cui viene distribuito GNU LilyPond. (Viene distribuito
+Mostra la garanzia con cui viene distribuito GNU LilyPond. (Distribuito
con @strong{NESSUNA GARANZIA}!)
@end table
@@ -449,12 +449,11 @@ localizzazione e i file di dati. Questa directory deve contenere
sottodirectory chiamate @file{ly/}, @file{ps/}, @file{tex/}, etc.
@item LANG
-Determina la lingua per i messaggi di avvertimento.
+Determina la lingua per i messaggi di avviso.
@item LILYPOND_GC_YIELD
-Con questa variabile si possono aggiustare il consumo di memoria e la
-performance. Ã? una percentuale che regola il comportamento di gestione della
-memoria. Con valori più alti il programma usa più memoria, con valori
+Una variabile, in forma di percentuale, che regola il modo in cui viene gestita
+la memoria. Con valori più alti il programma usa più memoria, con valori
più bassi usa più tempo della CPU. Il valore predefinito è @code{70}.
@end table
@@ -465,7 +464,7 @@ più bassi usa più tempo della CPU. Il valore predefinito è @code{70}.
@translationof LilyPond in chroot jail
Configurare un server perché esegua LilyPond in una gabbia chroot è un lavoro
-complicato. La procedura è spiegata sotto. Gli esempi si riferiscono a
+complesso. La procedura è spiegata sotto. Gli esempi si riferiscono a
Ubuntu Linux e potrebbero richiedere l'uso di @code{sudo} in alcune situazioni.
@itemize
@@ -605,7 +604,7 @@ successivo verrà saltato.
@item Errore fatale
@cindex errore fatale
C'è qualcosa di assolutamente sbagliato e LilyPond non può continuare. Questo
-accade raramente. La causa più tipica è un'errata installazione dei tipi di
+accade raramente. La causa più comune è un'errata installazione dei tipi di
carattere.
@item Errore Scheme
@@ -619,7 +618,7 @@ responsabile dell'errore.
@item Errore di programmazione
@cindex Errore di programmazione
-C'è stata una qualche incongruenza interna. Questi messaggi di errore
+Si è verificata una qualche incongruenza interna. Questi messaggi di errore
servono ad aiutare programmatori e debugger. Di solito si possono
ignorare. Talvolta sono talmente numerosi da nascondere il resto
dell'output.
@@ -628,7 +627,7 @@ dell'output.
@cindex Sospeso (core dumped)
Segnala un serio errore di programmazione che ha mandato in crash il
programma. Questi errori sono considerati critici. Se ti imbatti in un
-errore simile, invia una segnalazione di errori.
+errore simile, invia una segnalazione di errore.
@end table
@cindex errori, formato del messaggio
@@ -650,7 +649,7 @@ test.ly:2:19: error: not a duration: 5
5 g' @}
@end example
-Queste posizioni sono la migliore ipotesi di LilyPond a proposito del
+Queste posizioni indicano la migliore ipotesi di LilyPond a proposito del
punto in cui l'avvertimento o l'errore sono comparsi, ma (per loro
stessa natura) avvertimenti ed errori capitano quando succede qualcosa
di imprevisto. Se non riesci a vedere un errore nella riga indicata
@@ -665,8 +664,8 @@ Maggiori informazioni sugli errori si trovano in @ref{Errori comuni}.
@translationof Common errors
Le condizioni di errore descritte di seguito capitano spesso, ma la causa
-non è ovvia né facile da trovare. Una volta che si sono viste e comprese,
-è facile gestirle.
+non è ovvia né facile da trovare. Una volta che sono state individuate e
+comprese, è facile gestirle.
@menu
@@ -684,7 +683,7 @@ non è ovvia né facile da trovare. Una volta che si sono viste e comprese,
Se la musica esce dalla pagina al di là del margine destro o appare
eccessivamente compressa, quasi sempre è dovuto all'inserimento di
-una durata sbagliata di una nota, che fa sì che l'ultima nota di una misura si
+una durata errata di una nota, che fa sì che l'ultima nota di una misura si
estenda oltre la barra di divisione. Non è sbagliato se la nota finale di
una misura non termina entro la barra di divisione inserita automaticamente, perché
semplicemente si assume che la nota continui nella misura successiva. Ma se
@@ -697,12 +696,12 @@ ovvero quando tutte le note finiscono prima o alla fine della misura.
linea, portando a una linea di musica estremamente compressa o
a musica che esce dalla pagina.}
-La durata sbagliata può essere trovata facilmente se si usano i controlli di
+La durata errata può essere trovata facilmente se si usano i controlli di
battuta, si veda @ruser{Bar and bar number checks}.
-Se si vuole davvero avere una serie di di tali misure sovrapposte
+Se si vuole davvero ottenere una serie di tali misure sovrapposte
bisogna inserire una barra di divisione invisibile nel punto in cui
-si vuole l'interruzione di linea. Per i dettagli si veda @ruser{Bar lines}.
+si desidera l'interruzione di linea. Per i dettagli si veda @ruser{Bar lines}.
@node Appare un rigo in più
@@ -713,13 +712,12 @@ Se i contesti non sono creati esplicitamente con @code{\new} o
@code{\context}, saranno creati senza avviso appena si incontra
un comando che non può essere applicato a un contesto
esistente. Nelle partiture semplici la creazione automatica dei contesti
-è utile: infatti la maggior parte degli esempi nei manuali LilyPond sfruttano
-questa semplificazione. Ma talvolta la creazione silenziosa
-di contesti può causare nuovi righi o partiture non desiderate.
-Ad esempio, si potrebbe pensare che il seguente codice
-colori di rosso tutte le teste delle note nel rigo, ma in realtÃ
-produce due righi, di cui il più basso conserva il colore nero
-predefinito per le teste delle note.
+è utile: infatti la maggior parte degli esempi nei manuali LilyPond sfrutta
+questa semplificazione. Talvolta, però, la creazione silenziosa di contesti
+può causare la comparsa di nuovi righi o partiture non desiderate. Ad esempio,
+si potrebbe pensare che il seguente codice colori di rosso tutte le teste
+delle note nel rigo, ma in realtà produce due righi, di cui il più basso
+conserva il colore nero predefinito per le teste delle note.
@lilypond[quote,verbatim,relative=2]
\override Staff.NoteHead #'color = #red
@@ -767,10 +765,10 @@ Per correggere il problema basta istanziare esplicitamente il contesto
@unnumberedsubsec Errore apparente in @code{../ly/init.ly}
@translationof Apparent error in ../ly/init.ly
-Vari oscuri messaggi di errore relativi a errori di sintassi in
-@file{../ly/init.ly} possono apparire se il file di input non ha
-una forma corretta, ad esempio se contiene delle parentesi o
-delle virgolette che non sono chiuse correttamente.
+Possono apparire diversi strani messaggi di errore relativi a errori di
+sintassi in @file{../ly/init.ly} se il file di input non ha una forma corretta,
+ad esempio se contiene delle parentesi o delle virgolette non chiuse
+correttamente.
L'errore più comune è la mancanza di una parentesi graffa, (@code{@}}), alla fine
di un blocco @code{score}. In questo caso la soluzione è ovvia: controlla
@@ -779,15 +777,15 @@ di un file di input è descritta in @rlearning{Come funzionano i file di input d
Per evitare questi errori conviene usare un editor che evidenzi automaticamente
le parentesi e le graffe corrispondenti.
-Una seconda causa frequente di errore è la mancanza di uno spazio tra l'ultima
+Un'altra causa frequente di errore è la mancanza di uno spazio tra l'ultima
sillaba di un blocco di testo (lyrics) e la parentesi graffa che chiude il
-blocco, (@code{@}}). Senza questa separazione si considera che la graffa
-faccia parte della sillaba. Si consiglia di assicurarsi sempre che ci sia
+blocco, (@code{@}}). Senza questa separazione, la graffa viene considerata
+come parte della sillaba. Si consiglia di assicurarsi sempre che ci sia
uno spazio prima e dopo @emph{ogni} parentesi graffa. Per comprendere l'importanza
di questo quando si usa il testo, si veda @ruser{Entering lyrics}.
Questo messaggio di errore può apparire anche nel caso in cui sia omessa la
-virgoletta che chiude, (@code{"}). In questo caso il messaggio di errore
+virgoletta di chiusura, (@code{"}). In questo caso il messaggio di errore
@c keep "-matching straight in fancy editors
dovrebbe dare un numero di riga vicino alla riga sbagliata. La virgoletta
non chiusa sarà solitamente una o due righe sopra.
diff --git a/Documentation/it/usage/suggestions.itely b/Documentation/it/usage/suggestions.itely
new file mode 100644
index 0000000..878cf13
--- /dev/null
+++ b/Documentation/it/usage/suggestions.itely
@@ -0,0 +1,606 @@
+@c -*- coding: utf-8; mode: texinfo; -*-
+
+@ignore
+ Translation of GIT committish: 7ba0a22641cb0c7f5949d66a06d1e2e1fd0b3033
+
+ When revising a translation, copy the HEAD committish of the
+ version that you are working on. For details, see the Contributors'
+ Guide, node Updating translation committishes..
+@end ignore
+
+@c \version "2.13.36"
+
+@node Consigli su come scrivere i file
+@chapter Consigli su come scrivere i file
+@translationof Suggestions for writing files
+
+Ora puoi iniziare a scrivere file di input di LilyPond più grandi --
+non più i piccoli esempi del tutorial, ma brani completi.
+Ma qual è il modo migliore di farlo?
+
+Finché LilyPond comprende i file di input e produce l'output che
+desideri, non importa quale aspetto abbiano i file di input. Tuttavia,
+ci sono altre questioni da tenere a mente quando si scrivono
+file di input di LilyPond.
+
+@itemize
+@item Se fai un errore? La struttura di un file LilyPond può rendere
+l'individuazione di certi errori più facile (o più difficile).
+
+@item Se vuoi inviare i tuoi file di input a qualcuno? E se vuoi modificare
+i tuoi file di input dopo qualche anno? Alcuni file di input di LilyPond sono
+comprensibili a prima vista; altri ti possono lasciare perplesso per un'ora.
+
+@item Se vuoi aggiornare il tuo file per poterlo usare
+con una versione più recente di LilyPond? La sintassi di input cambia di
+tanto in tanto mentre LilyPond si evolve. Alcune modifiche possono essere
+fatte in automatico con @code{convert-ly}, ma altre potrebbero richiedere
+un intervento manuale. I file di input di LilyPond possono essere strutturati
+per poter essere aggiornati in modo più semplice (o più difficile).
+
+@end itemize
+
+@menu
+* Consigli generali::
+* Scrivere musica esistente::
+* Grandi progetti::
+* Risoluzione dei problemi::
+* Make e Makefiles::
+@end menu
+
+
+@node Consigli generali
+@section Consigli generali
+@translationof General suggestions
+
+Ecco alcuni consigli che possono aiutarti ad evitare o risolvere
+i problemi:
+
+@itemize
+@item @strong{Includi il numero di @code{\version} in ogni file}. Nota che tutti
+i modelli contengono l'informazione su @code{\version}. Si consiglia vivamente
+di includere sempre @code{\version}, non importa quanto piccolo possa essere
+il file. Per esperienza personale, è piuttosto frustrante cercare di ricordare
+quale versione di LilyPond si usava alcuni anni prima. @command{convert-ly}
+richiede che si dichiari la versione di LilyPond utilizzata.
+
+@item @strong{Includi i controlli}: @ruser{Bar and bar number checks},
+@ruser{Octave checks}. Se includi i controlli ogni tanto, allora se
+fai un errore lo puoi individuare più rapidamente. Cosa si intende per
+@q{ogni tanto}? Dipende dalla complessità della musica.
+Se la musica è molto semplice, magari solo una o due volte. Se la musica
+è molto complessa, ad ogni battuta.
+
+@item @strong{Una battuta per ogni linea di testo}. Se c'è qualcosa di
+complicato, nella musica stessa o nell'output che desideri, di solito è
+preferibile scrivere una sola battuta per linea. Risparmiare spazio sullo
+schermo concentrando otto battute per ogni riga non conviene affatto
+se poi devi fare il @q{debug} dei file di input.
+
+@item @strong{Inserisci dei commenti nei file di input}. Puoi usare i numeri
+di battuta (ogni tanto) o dei riferimenti ai temi musicali
+(@q{secondo tema nei violini,} @q{quarta variazione,} etc.). Potresti non
+aver bisogno dei commenti mentre scrivi il brano la prima volta, ma se due
+o tre anni dopo vuoi cambiare qualcosa o se vuoi dare il sorgente a un amico,
+sarà molto più difficile capire le tue intenzioni e la struttura del file
+se non sono presenti dei commenti.
+
+@item @strong{Indenta le parentesi graffe}. Molti problemi sono causati
+da uno squilibrio nel numero di @code{@{} e @code{@}}.
+
+@item @strong{Esplicita le durate} all'inizio delle sezioni e delle
+variabili. Se specifichi @code{c4 d e} all'inizio di un fraseggio
+(innvece di @code{c d e} soltanto) puoi evitare alcuni problemi
+quando riarrangi la musica successivamente.
+
+@item @strong{Separa le modifiche manuali (tweak)} dalle definizioni
+musicali. Vedi @rlearning{Ridurre lâ??input grazie a variabili e funzioni}, e
+@rlearning{Style sheets}.
+
+@end itemize
+
+
+@node Scrivere musica esistente
+@section Scrivere musica esistente
+@translationof Typesetting existing music
+
+Se stai scrivendo della musica da una partitura esistente (ovvero il brano
+di uno spartito già scritto),
+
+@itemize
+
+@item Inserisci in LilyPond le note del manoscritto (la copia fisica della
+musica) un sistema alla volta (ma sempre una battuta per linea di testo),
+e controlla ogni sistema quando ne completi uno. Puoi usare le proprietÃ
+@code{showLastLength} o @code{showFirstLength} per velocizzare
+l'elaborazione -- vedi @ruser{Skipping corrected music}.
+
+@item Definisci @code{mBreak = @{ \break @}} e inserisci @code{\mBreak}
+nel file di input ogni volta che nel manoscritto c'è un a capo. In questo
+modo è più semplice confrontare la musica generata da LilyPond con quella
+originale. Quando hai finito la revisione della partitura, puoi
+definire @code{mBreak = @{ @}} per eliminare tutte queste interruzioni di
+riga. Così LilyPond potrà inserire le interruzioni dove ritiene stiano
+meglio.
+
+@item Quando si inserisce una parte per uno strumento traspositore in una
+variabile, si consiglia di avvolgere le note tra parentesi
+
+@example
+\transpose c altezza-naturale @{...@}
+@end example
+
+@noindent
+(dove @code{altezza-naturale} è l'altezza dello strumento) in modo
+che la musica contenuta nella variabile sia effettivamente in Do. Puoi trasporla
+all'indietro quando la variabile viene usata, se richiesto, ma potresti non
+desiderarlo (ad esempio quando si stampa una partitura in intonazione reale,
+quando si converte una parte per trombone dalla chiave di Sol alla chiave di
+basso, etc.). Errori nelle trasposizioni sono meno probabili se tutta la musica
+contenuta nelle variabili è ad un'altezza costante.
+
+Inoltre, trasponi sempre verso/dal Do. Questo significa che le uniche altre
+tonalità che userai sono le altezze naturali degli strumenti - bes
+per una tromba in Si bemolle, aes per un clarinetto in La bemolle, etc.
+
+@end itemize
+
+
+@node Grandi progetti
+@section Grandi progetti
+@translationof Large projects
+
+Quando si lavora a un grande progetto, definire una struttura chiara nel
+file di input diventa vitale.
+
+@itemize
+
+@item @strong{Usa una variabile per ogni voce}, con un minimo di
+struttura nella definizione. La struttura della sezione
+@code{\score} è la parte che più probabilmente cambierà ;
+la definizione di @code{violin} è molto improbabile che cambi
+in una nuova versione di LilyPond.
+
+@example
+violin = \relative c'' @{
+g4 c'8. e16
+@}
+...
+\score @{
+ \new GrandStaff @{
+ \new Staff @{
+ \violin
+ @}
+ @}
+@}
+@end example
+
+@item @strong{Separa le modifiche manuali (tweak) dalle definizioni musicali}. Questo
+punto è stato menzionato prima, ma nei grandi progetti diventa di vitale
+importanza. Potrebbe essere necessario modificare la definizione
+di @code{fthenp}, ma si dovrebbe farlo una volta sola e senza toccare
+niente in @code{violin}.
+
+@example
+fthenp = _\markup@{
+ \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
+violin = \relative c'' @{
+g4\fthenp c'8. e16
+@}
+@end example
+
+@end itemize
+
+
+@node Risoluzione dei problemi
+@section Risoluzione dei problemi
+@translationof Troubleshooting
+
+Prima o poi ti capiterà di scrivere un file che LilyPond non
+riesce a compilare. I messaggi inviati da LilyPond potrebbero aiutarti
+a trovare l'errore, ma in molti casi devi fare qualche ricerca
+per individuare l'origine del problema.
+
+Gli strumenti più potenti per questo scopo sono il commento della
+linea singola (indicato da @code{%}) e il commento di blocco
+(indicato da @code{%@{ ... %@}}). Se non sai dove sta il problema,
+inizia col commentare ampie parti del file di input. Dopo aver commentato
+una sezione, prova a compilare di nuovo il file. Se funziona, allora il
+problema deve trovarsi nella parte che hai appena commentato. Se non
+funziona, continua a commentare il materiale finché non hai qualcosa
+che funziona.
+
+Nel caso più estremo, potresti finire con soltanto
+
+@example
+\score @{
+ <<
+ % \melody
+ % \harmony
+ % \bass
+ >>
+ \layout@{@}
+@}
+@end example
+
+@noindent
+(in altre parole, un file senza musica)
+
+Se accade questo, non rinunciare. Decommenta un pezzetto -- ad esempio,
+la parte di basso -- e vedi se funziona. Se non funziona,
+allora commenta tutta la musica del basso (ma lascia
+@code{\bass} in @code{\score} non commentato).
+
+@example
+bass = \relative c' @{
+%@{
+ c4 c c c
+ d d d d
+%@}
+@}
+@end example
+
+Ora inizia piano piano a decommentare la parte di
+@code{bass} finché non trovi la linea che causa il problema.
+
+Un'altra tecnica di debug molto utile consiste nel creare
+@rweb{Esempi minimi}.
+
+
+@node Make e Makefiles
+@section Make e Makefiles
+@translationof Make and Makefiles
+
+@cindex makefiles
+@cindex make
+
+Tutte le piattaforme su cui Lilypond può essere installato supportano un
+software chiamato @code{make}. Questo software legge un file speciale chiamato
+@code{Makefile} che definisce quali file dipendono da quali altri file e quali
+comandi bisogna dare al sistema operativo per produrre un file da un
+altro. Ad esempio makefile può spiegare come generare
+@file{ballad.pdf} e @file{ballad.midi} da @file{ballad.ly} eseguendo
+Lilypond.
+
+Ci sono situazioni in cui è una buona idea creare un @code{Makefile}
+per il proprio progetto, per proprio comodo o come cortesia
+per altri che potrebbero avere accesso ai file sorgente.
+Questo vale per i progetti molto ampi con tanti file inclusi e
+diverse opzioni di output (ad esempio, partitura completa, parti, partitura
+del direttore, riduzione per pianoforte, etc.), o per progetti che
+richiedono comandi difficili per la compilazione (come i progetti che
+usano @code{lilypond-book}). Makefiles variano molto in complessitÃ
+e flessibilità , in base alle necessità e alle abilità degli autori.
+Il programma GNU Make è installato nelle distribuzioni GNU/Linux
+e su MacOS X ed è disponibile anche per Windows.
+
+Si veda il @strong{Manuale di GNU Make} per conoscere in dettaglio l'uso di
+@code{make}, dato che quel che segue dà solo un'idea quel che può fare.
+
+I comandi per definire delle regole in un makefile cambiano in base
+alla piattaforma; ad esempio le varie forme di Linux e
+MacOS usano @code{bash}, mentre Windows usa @code{cmd}. Nota che su
+MacOS X bisogna configurare il sistema per usare l'interprete da linea
+di comando. Di seguito alcuni makefile di esempio, con versioni sia per
+Linux/MacOS sia per Windows.
+
+Il primo esempio è per un'opera per orchestra in quattro
+movimenti e ha la seguente struttura di directory:
+
+@example
+Symphony/
+|-- MIDI/
+|-- Makefile
+|-- Notes/
+| |-- cello.ily
+| |-- figures.ily
+| |-- horn.ily
+| |-- oboe.ily
+| |-- trioString.ily
+| |-- viola.ily
+| |-- violinOne.ily
+| `-- violinTwo.ily
+|-- PDF/
+|-- Parts/
+| |-- symphony-cello.ly
+| |-- symphony-horn.ly
+| |-- symphony-oboes.ly
+| |-- symphony-viola.ly
+| |-- symphony-violinOne.ly
+| `-- symphony-violinTwo.ly
+|-- Scores/
+| |-- symphony.ly
+| |-- symphonyI.ly
+| |-- symphonyII.ly
+| |-- symphonyIII.ly
+| `-- symphonyIV.ly
+`-- symphonyDefs.ily
+@end example
+
+I file @file{.ly} nelle directory @file{Scores} e
+@file{Parts} prendono le note dai file @file{.ily}
+nella directory @file{Notes}:
+
+@example
+%%% inizio del file "symphony-cello.ly"
+\include ../definitions.ily
+\include ../Notes/cello.ily
+@end example
+
+Il makefile avrà i target di @code{score} (l'intero brano in partitura
+completa), @code{movements} (movimenti individuali in partitura completa),
+e @code{parts} (parti individuali per i musicisti). C'è anche un
+target @code{archive} che creerà un archivio compresso dei file sorgenti,
+utile per la condivisione via web o email. Ecco un esempio di
+makefile per GNU/Linux e MacOS X. Dovrebbe essere salvato col
+nome @code{Makefile} nella directory principale del progetto:
+
+@warning{Quando si definisce un target o una regola di pattern, le
+linee successive devono iniziare con i tabulatori, non con gli spazi.}
+
+@example
+# Il prefisso al nome dei file di output
+piece = symphony
+# Determinazione del numero dei processori
+CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
+# Il comando per eseguire lilypond
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click -djob-count=$(CPU_CORES)
+
+# I suffissi usati in questo Makefile.
+.SUFFIXES: .ly .ily .pdf .midi
+
+# I file di input e di output vengono cercati nelle directory elencate
+# nella variabile VPATH. Tutte queste sono sottodirectory della directory
+# corrente (assegnata dalla variabile `CURDIR' di GNU make).
+VPATH = \
+ $(CURDIR)/Scores \
+ $(CURDIR)/PDF \
+ $(CURDIR)/Parts \
+ $(CURDIR)/Notes
+
+# La regola di pattern per creare i file PDF e MIDI da un file di input LY.
+# I file di output .pdf vengono messi nella sottodirectory `PDF', mentre i file
+# .midi vanno nella sottodirectory `MIDI'.
+%.pdf %.midi: %.ly
+ $(LILY_CMD) $<; \ # questa linea inizia con una tabulazione
+ if test -f "$*.pdf"; then \
+ mv "$*.pdf" PDF/; \
+ fi; \
+ if test -f "$*.midi"; then \
+ mv "$*.midi" MIDI/; \
+ fi
+
+notes = \
+ cello.ily \
+ horn.ily \
+ oboe.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+# Le dipendenze dei movimenti.
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+# Le dipendenze della partitura completa.
+$(piece).pdf: $(piece).ly $(notes)
+
+# Le dipendenze delle parti.
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+# Lanciare `make score' per generare la partitura completa di tutti i quattro
+# movimenti in un unico file.
+.PHONY: score
+score: $(piece).pdf
+
+# Lanciare `make parts' per generare tutte le parti.
+# Lanciare `make foo.pdf' per generare la parte per lo strumento `foo'.
+# Esempio: `make symphony-cello.pdf'.
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+# Lanciare `make movements' per generare i file per i
+# quattro movimenti separatamente.
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+
+archive:
+ tar -cvvf stamitz.tar \ # questa linea inizia con una tabulazione
+ --exclude=*pdf --exclude=*~ \
+ --exclude=*midi --exclude=*.tar \
+ ../Stamitz/*
+@end example
+
+
+Ci sono complicazioni specifiche nella piattaforma Windows. Dopo aver
+scaricato e installato GNU Make per Windows, bisogna impostare il percorso
+corretto nelle variabili d'ambiente di sistema perché la
+shell DOS possa trovare il programma Make. Per farlo, clicca col tasto destro
+del mouse su "My Computer," poi scegli @code{Proprietà } e
+@code{Avanzate}. Clicca su @code{Variabili di ambiente}, e poi nel
+pannello @code{Variabili di Sistema}, nella sezione @code{Percorso}, clicca su
+@code{modifica} e aggiungi il percorso al file eseguibile GNU Make, che
+avrà un aspetto simile:
+
+@example
+C:\Program Files\GnuWin32\bin
+@end example
+
+Lo stesso makefile deve essere modificato per gestire diversi comandi
+shell e gli spazi che sono presenti in alcune directory predefinite
+di sistema. Il target @code{archive} target viene tolto perché Windows
+non ha il comando @code{tar}; inoltre Windows ha una diversa estensione
+predefinita per i file midi.
+
+
+@example
+## VERSIONE DI WINDOWS
+##
+piece = symphony
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click \
+ -djob-count=$(NUMBER_OF_PROCESSORS)
+
+#get the 8.3 name of CURDIR (workaround for spaces in PATH)
+workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
+ do @@echo %%~sb)
+
+.SUFFIXES: .ly .ily .pdf .mid
+
+VPATH = \
+ $(workdir)/Scores \
+ $(workdir)/PDF \
+ $(workdir)/Parts \
+ $(workdir)/Notes
+
+%.pdf %.mid: %.ly
+ $(LILY_CMD) $< # questa linea inizia con una tabulazione
+ if exist "$*.pdf" move /Y "$*.pdf" PDF/
+ if exist "$*.mid" move /Y "$*.mid" MIDI/
+
+notes = \
+ cello.ily \
+ figures.ily \
+ horn.ily \
+ oboe.ily \
+ trioString.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+$(piece).pdf: $(piece).ly $(notes)
+
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+.PHONY: score
+score: $(piece).pdf
+
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+@end example
+
+
+Il Makefile seguente è per un documento @command{lilypond-book} fatto con
+LaTeX. Questo progetto ha un indice, dunque il comando @command{latex} deve
+essere eseguito due volte per aggiornare i collegamenti. I file di output
+sono tutti salvati nella directory @code{out} per i file .pdf e nella directory
+@code{htmlout} per i file html.
+
+@example
+SHELL=/bin/sh
+FILE=myproject
+OUTDIR=out
+WEBDIR=htmlout
+VIEWER=acroread
+BROWSER=firefox
+LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
+LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
+PDF=cd $(OUTDIR) && pdflatex $(FILE)
+HTML=cd $(WEBDIR) && latex2html $(FILE)
+INDEX=cd $(OUTDIR) && makeindex $(FILE)
+PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
+
+all: pdf web keep
+
+pdf:
+ $(LILYBOOK_PDF) # inizia con una tabulazione
+ $(PDF) # inizia con una tabulazione
+ $(INDEX) # inizia con una tabulazione
+ $(PDF) # inizia con una tabulazione
+ $(PREVIEW) # inizia con una tabulazione
+
+web:
+ $(LILYBOOK_HTML) # inizia con una tabulazione
+ $(HTML) # inizia con una tabulazione
+ cp -R $(WEBDIR)/$(FILE)/ ./ # inizia con una tabulazione
+ $(BROWSER) $(FILE)/$(FILE).html & # inizia con una tabulazione
+
+keep: pdf
+ cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # inizia con una tabulazione
+
+clean:
+ rm -rf $(OUTDIR) # inizia con una tabulazione
+
+web-clean:
+ rm -rf $(WEBDIR) # inizia con una tabulazione
+
+archive:
+ tar -cvvf myproject.tar \ # inizia questa linea con una tabulazione
+ --exclude=out/* \
+ --exclude=htmlout/* \
+ --exclude=myproject/* \
+ --exclude=*midi \
+ --exclude=*pdf \
+ --exclude=*~ \
+ ../MyProject/*
+@end example
+
+@c TODO: make this thing work on Windows
+
+Il makefile precedente non funziona su Windows. Un'alternativa per
+gli utenti Windows consiste nel creare un semplice file batch
+contenente i comandi per la compilazione. Questo file non terrÃ
+traccia delle dipendenze come fa invece un makefile, ma almeno riduce
+il processo di compilazione a un solo comando. Salva il codice
+seguente come @command{build.bat} o @command{build.cmd}.
+Il file batch può essere eseguito nel prompt DOS o semplicemente con
+un doppio clic sulla sua icona.
+
+@example
+lilypond-book --output=out --pdf myproject.lytex
+cd out
+pdflatex myproject
+makeindex myproject
+pdflatex myproject
+cd ..
+copy out\myproject.pdf MyProject.pdf
+@end example
+
+
+@seealso
+
+Questo manuale:
+@ref{Uso da linea di comando},
+@ref{lilypond-book}
+
diff --git a/Documentation/it/usage/updating.itely b/Documentation/it/usage/updating.itely
index 4a3865d..fa6e0ec 100644
--- a/Documentation/it/usage/updating.itely
+++ b/Documentation/it/usage/updating.itely
@@ -43,8 +43,8 @@ gran parte dei cambiamenti di sintassi tra le versioni di LilyPond.
La sintassi di input di LilyPond talvolta cambia. Via via che LilyPond
migliora, la sintassi (il linguaggio dell'input) viene modificata di
conseguenza. Queste modifiche vengono fatte a volte per far sì che l'input
-sia più facile da leggere e da scrivere e a volte per fornire nuove
-funzionalità di LilyPond.
+sia più facile da leggere e da scrivere e a volte per aggiungere a LilyPond
+nuove funzionalità .
Ad esempio, tutti i nomi delle proprietà di @code{\paper} e @code{\layout}
dovrebbero essere scritte nella forma @code{primo-secondo-terzo}.
@@ -85,7 +85,7 @@ nella directory che contiene il file. Questo comando aggiornerÃ
@file{miofile.ly~}.
@warning{@command{convert-ly} converte sempre fino all'ultimo cambiamento di
-sintassi da lui gestito. Questo significa che il numero di @code{\version}
+sintassi gestito. Questo significa che il numero di @code{\version}
che appare nel file convertito è di solito inferiore al numero di versione di
@command{convert-ly}.}
@@ -96,14 +96,13 @@ convert-ly -e *.ly
@end example
Altrimenti, se si desidera specificare un nome diverso per il file
-aggiornato, lasciando non modificati il file originale e il suo nome,
-si usa
+aggiornato, senza modificare il file originale e il suo nome, si usa
@example
convert-ly miofile.ly > mionuovofile.ly
@end example
-Il programma elencherà i numeri di versione per i quali sono state fatte
+Il programma elencherà i numeri di versione per i quali sono state eseguite
le conversioni. Se non vengono elencati dei numeri di versione il file è
già aggiornato.
@@ -130,12 +129,12 @@ Esistono le seguenti opzioni:
@table @code
@item -e,--edit
-Applica le conversioni direttamente nel file di input, sostituendo
+Applica le conversioni direttamente nel file di input, modificando
l'originale.
@item -f,--from=@var{from-patchlevel}
Imposta la versione da cui convertire. Se non viene impostata, @command{convert-ly}
-la indovinerà in base alla stringa @code{\version} presente nel file.
+la ricaverà dalla stringa @code{\version} presente nel file.
Esempio: @code{--from=2.10.25}
@item -n,--no-version
@@ -146,11 +145,11 @@ nell'output. Questa opzione lo impedisce.
Mostra tutte le conversioni conosciute ed esce.
@item --to=@var{to-patchlevel}
-Imposta l'obiettivo di versione della conversione. L'impostazione predefinita
+Imposta la versione obiettivo della conversione. L'impostazione predefinita
è l'ultima versione disponibile. Esempio: @code{--to=2.12.2}
@item -h, --help
-Stampa l'aiuto per l'utilizzo.
+Mostra la schermata di aiuto.
@end table
Per aggiornare i frammenti LilyPond presenti nei file texinfo, si usa
@@ -172,8 +171,8 @@ convert-ly --from=... --to=... -s
Quando si esegue convert-ly in una finestra del Prompt dei comandi in Windows
su un file il cui nome o percorso contengano degli spazi,
-è necessario circondare interamente il nome del file di input con tre
-(!) doppie virgolette:
+è necessario includere tutto il nome del file di input con tre
+(!) virgolette doppie:
@example
convert-ly """D:/Mie Partiture/Ode.ly""" > "D:/Mie Partiture/new Ode.ly"
@@ -194,9 +193,9 @@ Nella finestra del Prompt dei comandi di Windows il comando corrispondente è
for %x in (*.ly) do convert-ly -e """%x"""
@end example
-Non vengono gestite tutti i cambiamenti del linguaggio. Si può specificare solo
+Non vengono gestiti tutti i cambiamenti del linguaggio. Si può specificare solo
un'opzione di output. Ã? piuttosto improbabile che si aggiornino automaticamente
-il codice scheme e le interfacce di scheme di LilyPond; tienti pronto a
+il codice scheme e le interfacce di scheme di LilyPond; tieniti pronto a
correggere a mano il codice scheme.
@@ -205,16 +204,16 @@ correggere a mano il codice scheme.
@translationof Manual conversions
In teoria, un programma come @command{convert-ly} potrebbe gestire qualsiasi
-cambiamento di sintassi. Dopo tutto, un programma per computer interpreta la
+cambiamento di sintassi. Dopo tutto, un programma per computer interpreta
la vecchia versione e la nuova versione, quindi un altro programma
può tradurre un file in un altro@footnote{O almeno questo è possibile
in qualsiasi file LilyPond che non contenga codice scheme. Se c'è del
codice scheme nel file, allora il file LilyPond contiene un linguaggio
-Turing-completo, ed è possibile imbattersi in problemi col famoso
+Turing-completo, ed è possibile imbattersi in problemi col famigerato
@qq{Problema dell'arresto} in informatica.}.
Tuttavia il progetto LilyPond ha risorse limitate: non tutte le
-conversioni sono compiute automaticamente. Qui sotto si trova una lista
+conversioni sono compiute automaticamente. Di seguito è riportato l'elenco
dei problemi noti.
--
1.7.4.1
--=-G46gvrlWjXPx7p6oOqcB--