[RFR] po4a://developers-reference/it.po (parte 1)

[Daniele Forsi]

2014-06-05 16:09 GMT+02:00 Pierangelo Mancusi:

> ecco la prima (di due parti) della Debian Developer's Reference.
> ovviemente seguo il prezioso suggerimento di Beatrice nel pubblicare il file
> in due parti distinte.

questa parte era finita nel mio SPAM ma mi sembra che non sia stato revisionato

> msgid "Best Packaging Practices"
> msgstr "Best Practices per la Pacchettizzazione"

solo l'iniziale maiuscola (mi sembra l'unico titolo con questo problema)

> "Questo capitolo fornisce alcune best practices per gli sviluppatori Debian.

non so cosa suggerire per "best practices"

> Since <filename>debian/rules</filename> controls the build process "

> Da quando il <filename>debian/rules</filename> controlla il "
> "processo di generazione

s/Da quando/Dal momento che/

> msgid "Helper scripts"
> msgstr "Scripts di supporto "

togliere lo spazio finale

> "L'idea nell'utilizzo dei script di aiuto in <filename>debian/rules</"

s/dei/degli/

> "<filename>/usr/share/menu</filename> (or <filename>/usr/lib/menu</filename>

s/or/o/

> "Gli scripts di supporto si occupano di questi problemi. Supponendo che ci

s/scripts/script/ anche in almeno un'altra

> "effettuati nello script helper; succesivamente i pacchetti avranno solo "

s/succesivamente/successivamente/

> "come  <systemitem role=\"package\">debmake</systemitem>, erano monolitici:

togliere il doppio spazio prima di <
bisognerebbe leggerlo in formato HTML o PDF per vedere facilmente questi errori

> "non si poteva scegliere quale parte dell' helper si riteneva utile, ma si "

togliere lo spazio dopo l'apostrofo

> "programmi<command>dh_*</command>.

aggiungere uno spazio dopo "programmi"

> ">), can be used to convert a vanilla source package to a <systemitem role="

> "può essere utilizzato per convertire un pacchetto sorgente vaniglia in un "

tradurrei "vanilla" con "normale" o "originale", anche più avanti

> dal <systemitem
> role=\"package"
> "\">dh-make</systemitem> pacchetto

"pacchetto" va dopo "dal"

> "its expectations and behavior."

> le sue previsioni e "
> "comportamenti."

"cosa si aspetta e il suo comportamento." (oppure
s/comportamento/funzionamento/ visto che non è un essere vivente)

> "Alcune persone pensano che i files vaniglia di <filename>debian/rules</"

s/files/file/

> "Big, complex packages may have many bugs that you need to deal with.

> "Grandi, pacchetti complessi possono avere molti bug ci si deve rapportare.

s/ci/con cui ci/

> You can't take "
> "the total set of diffs (e.g., from <filename>.diff.gz</filename>) and work
> "
> "out which patch sets to back out as a unit as bugs are fixed upstream."

> Non si può prendere l'insieme totale di diffs (ad esempio, da "
> "<filename>.diff.gz</filename>) e capire quali insiemi di patch occorrono
> per "
> "tornare indietro di una unità a seconda di quanti bugs sono stati corretti
> "
> "nell'upstream."

s/diffs/diff/ o "differenze"?
il resto non mi torna
"patch sets" direi semplicemente "patch"
"to back out as a unit" il dizionario mi dice "to back
out"="ritirarsi" direi qualcosa come "abbandonare in blocco"
"as bugs are fixed" direi "man mano che i bug vengono corretti"

quindi, anche se non mi torna tanto: "Non si può prendere l'insieme
totale dei diff ... e capire quali patch possono essere abbandonate in
blocco man mano che i bug vengono corretti upstream."
(non so se "upstream" è tradotto da altre parti)

> "spacchettato le patch elencate nel  <filename>debian/patches/series</"

doppio spazio, anche in altre frasi non lo segnalo più, ti conviene
fare una ricerca dei doppi spazi

> "Quando si utilizza il più anziano sourgente «1.0», è anche possibile "

s/sourgente/sorgente/

> "separare le patches, ma un sistema di patch dedicato deve essere

s/patches/patch/

> "a dependency on the <literal>patch</literal> rule.  Conversely, they are "
> "reverted in the <literal>clean</literal> rule, through a dependency on the

> "<literal>patch</literal>. Al contrario, essi sono ritornati nella regola
> </"
> "literal>clean <literal>, attraverso una dipendenza dalla regola "
> "<literal>unpatch</literal> ."

non mi torna reverted->ritornati
piuttosto qualcosa come annullati

> "A single source package will often build several binary packages, either to

> "Un singolo pacchetto sorgente costruirà diversi pacchetti binari, sia per "

manca "often"

> in modo che l'utente
> può "
> "installare

s/può/possa/

> "Il primo caso è un pò più difficile in quanto comporta molteplici "

s/pò/po'/

> "La descrizione del pacchetto, come definito dal corrispondente campo nel "

s/definito/definita/ il soggetto è "descrizione"

> For instance, "
> "development packages are for developers, and can be technical in their "
> "language.

> Per esempio, pacchetti di sviluppo sono per gli sviluppatori, e
> "possono essere di natura tecnica nella loro lingua.

direi s/lingua/linguaggio/

> Applicazioni più "
> "generiche, come editors

s/editors/gli editor/

> #. type: Content of: <chapter><section><section><para>
> #: best-pkging-practices.dbk:188
> msgid ""
> "Our review of package descriptions lead us to conclude that most package "
> "descriptions are technical, that is, are not written to make sense for
> non-"
> "technical users.  Unless your package really is only for technical users, "
> "this is a problem."
> msgstr ""
> "La nostra recensione delle descrizioni dei pacchetti ci porta a concludere
> "
> "che la maggior parte delle descrizioni dei pacchetti sono di natura
> tecnica, "
> "cosi è, non sono scritti per avere senso per gli utenti non tecnici. A meno
> "
> "che il vostro pacchetto è realmente solo per utenti tecnici, questo "
> "costituisce un problema."

direi s/recensione/analisi/
s/scritti/scritte/
s/è realmente/non sia realmente/

> #. type: Content of: <chapter><section><section><para>
> #: best-pkging-practices.dbk:201
> msgid ""
> "Be objective.  Package descriptions are not the place for advocating your "
> "package, no matter how much you love it.  Remember that the reader may not
> "
> "care about the same things you care about."
> msgstr ""
> "Siate obiettivi. Le descrizioni dei pacchetti non sono il posto per "
> "promuovere il vostro pacchetto, non importa quanto lo amiate. Ricordate che
> "
> "il lettore non può occuparsi delle stesse cose che vi interessano."

"...potrebbe non essere interessato alle..."

> "References to the names of any other software packages, protocol names, "
> "standards, or specifications should use their canonical forms, if one "
> "exists.

> "I riferimenti ai nomi di eventuali altri pacchetti software, nomi di "
> "protocollo, standard o specifiche dovrebbero utilizzare le loro forme "
> "canoniche, se ne esiste una.

non mi torna il plurale e il singolare:
"utilizzare le loro forme canoniche, se ne esistono."
oppure
"utilizzare la forma canonica, se ne esiste una."

>  For example, use X Window System, X11, or X; not X Windows, X-"
> "Windows, or X Window.  Use GTK+, not GTK or gtk.  Use GNOME, not Gnome.

> Ad esempio, utilizzate X Window System, X11 o
> "X, non X di Windows, X-Windows o X Window.

toglierei "di"

> #. type: Content of: <chapter><section><section><para>
> #: best-pkging-practices.dbk:221
> msgid ""
> "Policy says the synopsis line (the short description) must be concise, not
> "
> "repeating the package name, but also informative."
> msgstr ""
> "la Policy dice che la linea di sinossi (la breve descrizione) deve essere "
> "concisa, non ripetendo il nome del pacchetto, ma anche informativo."

iniziale maiuscola perché dal commento dovrebbe essere un paragrafo

> #. type: Content of: <chapter><section><section><para>
> #: best-pkging-practices.dbk:244
> msgid ""
> "Sets of related packages may use an alternative scheme that divides the "
> "synopsis into two parts, the first a description of the whole suite and the
> "
> "second a summary of the package's role within it:"
> msgstr ""
> "Insiemi di pacchetti correlati possono utilizzare uno schema alternativo
> che "
> "divide la sinossi in due parti, la prima una descrizione di tutta la suite
> e "
> "la seconda una sintesi del ruolo del pacchetto all'interno dello schema:"

secondo me "within it" si riferisce a "whole suite"

> "The long description is the primary information available to the user about

> "La descrizione lunga è la prima informazione sul pacchetto disponibile agli

s/prima/principale/

> Entrambi "
> "<command>ispell</command> e <command>aspell</command> hanno modalità "
> "speciali per il controllo del file <filename>debian/control</filename>:"

s/Entrambi ... e/Sia ... che/ oppure toglierlo del tutto

> #. type: Content of: <chapter><section><section><screen>
> #: best-pkging-practices.dbk:299
> #, no-wrap
> msgid "ispell -d american -g debian/control\n"
> msgstr ""
> "ispell -d american -g debian/control\n"
> " "
>
> #. type: Content of: <chapter><section><section><screen>
> #: best-pkging-practices.dbk:302
> #, no-wrap
> msgid "aspell -d en -D -c debian/control\n"
> msgstr ""
> "aspell -d en -D -c debian/control\n"
> " "

in entrambe togliere lo spazio dall'ultima riga

> #. type: Content of:
> <chapter><section><section><itemizedlist><listitem><para>
> #: best-pkging-practices.dbk:310
> msgid ""
> "What does the package do? If it is an add-on to another package, then the "
> "short description of the package we are an add-on to should be put in
> here."
> msgstr ""
> "Che cosa fa il pacchetto? Se si tratta di un add-on per un altro pacchetto,
> "
> "allora nella breve descrizione del pacchetto  andrebbe inserito che si "
> "tratta di un add-on."

la traduzione è diversa e poi cercherei di tradurre "add-on" ad
esempio come "aggiunta" o "componente aggiuntivo"

> #. type: Content of:
> <chapter><section><section><itemizedlist><listitem><para>
> #: best-pkging-practices.dbk:329
> msgid ""
> "If the package is <literal>experimental</literal>, or there are other "
> "reasons it should not be used, if there are other packages that should be "
> "used instead, it should be here as well."
> msgstr ""
> "Se il pacchetto è <literal>experimental</literal>, o ci sono altri motivi "
> "per i quali non dovrebbe essere usato, se invece ci sono altri pacchetti
> che "
> "dovrebbero essere utilizzati, esso dovrebbe essere indicato."

non mi torna "esso", usare "ciò"? Oppure girare la frase aggiungendo
un altro "o" per l'ultima parte:
"Dovrebbe essere indicato se il pacchetto è... o se invece..."

> "In che modo questo pacchetto si differenzia da altri? E'

s/E'/È/

> #. type: Content of: <chapter><section><section><title>
> #: best-pkging-practices.dbk:349
> msgid "Upstream home page"
> msgstr "Upstream home page"

non so cosa suggerire

>  Adding this information in the "
> "package description itself is considered deprecated."

> L'aggiunta di queste informazioni
> nella "
> "descrizione del stesso pacchetto  è considerato obsoleto."

"this information" si riferisce all'URL, "itself" si riferisce a
"description" e non lo tradurrei e non torna il maschile:
"L'aggiunta di questa informazione nella descrizione del pacchetto è
considerata obsoleta."

> #. type: Content of: <chapter><section><section><section><para>
> #: best-pkging-practices.dbk:367
> msgid ""
> "Value of this field should be a <literal>http://</literal> URL pointing to
> a "
> "web-browsable copy of the Version Control System repository used to
> maintain "
> "the given package, if available."
> msgstr ""
> "Il valore di questo campo dovrebbe essere un <literal>http://</literal> URL
> "
> "che punta a una copia web navigabile della Version Control System
> utilizzato "
> "per mantenere il pacchetto , se disponibile."

URL va davanti
s/della/del/
e c'è uno spazio in più davanti alla virgola

> E "
> "'consentito specificare diversi campi VCS per lo stesso pacchetto: saranno

s/E 'consentito/È consentito/

> "automatic building of the latest VCS version of the given package.  To this

> "includere building automatici della versione più recente versione VCS del "

parola duplicata: "versione"

> "dato pacchetto . A tal fine la posizione a cui punta il campo dovrebbe "

spazio prima del punto

> "filename>. E' anche mostrato l'uso dei campi del <literal>Vcs-Browser</"
> "literal> e <literal>Homepage</literal> descritti precedentemente ."

ti conviene fare una ricerca per questi errori ricorrenti che non segnalo più:
E'
spazio prima del punto

> "There's no need to elaborate the trivial and obvious changes.

> "Non c'è bisogno di elaborare le modifiche banali e ovvie.

direi s/elaborare/descrivere/

> "Utilizzate L'Inglese comune in modo che la maggior parte dei lettori può "
> "comprenderlo.

s/L'Inglese/l'inglese/
s/può/possa/

> "i cambiamenti che chiudono i bug, soprattutto per i bug segnalati dagli "
> "utenti che non ti sembrano particolarmente smaliziati dal punto di vista "

s/ti/vi/

> However, there's no need to explicitly list each
> "
> "and every last one of the changed files

> "Tuttavia, non c'è bisogno di elencarli "
> "esplicitamente tutti e tutti gli ultimi file modificati

s/elencarli/elencare/
e comunque direi "...elencare uno per uno tutti i file modificati"

> "cambiamento è stato piccolo o ripetitivo. È possibile utilizzare i
> caratteri "
> "jolly."

metacaratteri

> "Le voci changelog<emphasis role=\"strong\">non</emphasis> dovrebbero "

manca lo spazio

> "essere utilizzatie per discussioni casuali con i chi ha segnalato il bug "

s/utilizzatie/utilizzate/
s/i chi/chi/

> "informazioni al riguardo), dichiarazioni generali sulla la vita, l'universo

s/sulla la/sulla/

> "Siccome ora abbiamo version tracking , è sufficiente per mantenere le voci

spazio

> "del changelog NMUed ed a citatelo  nella vostra voce del changelog."

NUMed era un participio passato, più altri errori

> msgid "  * Fixed all outstanding bugs.\n"
> msgstr "* Corretti tutti i bug aperti.\n"

potrebbe essere importante mantenere i due spazi iniziali

> msgid "  * Applied patch from Jane Random.\n"
> msgstr "* Patch applicata da Jane Random.\n"

potrebbe essere importante mantenere i due spazi iniziali e poi:
"  * Applicata patch di Jane Random.\n"

> msgid "  * Late night install target overhaul.\n"
> msgstr "* Installazione notturna della revisione. \n"

potrebbe essere importante mantenere i due spazi iniziali

> #. type: Content of: <chapter><section><section><para>
> #: best-pkging-practices.dbk:528
> msgid ""
> "Overhaul which accomplished what? Is the mention of late night supposed to
> "
> "remind us that we shouldn't trust that code?"
> msgstr ""
> "Revisione che ha completato cosa? L'ipotetica citazione notturna è stata a
> "
> "ricordarci che non dovevamo fidarci di quel codice?"

s/dovevamo/dovremmo/

> msgid "  * Fix vsync FU w/ ancient CRTs.\n"
> msgstr ""
> "  * Fix vsync FU w/ ancient CRTs.\n"
> " "

tradurre e togliere lo spazio in più sulla seconda riga

> msgid "  * This is not a bug, closes: #nnnnnn.\n"
> msgstr "* Questo non è un bug, chiude:. # nnnnnn \n"

potrebbe essere importante mantenere i due spazi iniziali

> #. type: Content of: <chapter><section><section><screen>
> #: best-pkging-practices.dbk:547
> #, no-wrap
> msgid "  * Has been fixed for ages, but I forgot to close; closes:
> #54321.\n"
> msgstr ""
> "* È stato fissato da tempo, ma ho dimenticato di chiudere; chiude: #54321
> \n"
> "."

s/fissato/corretto/
il punto va prima dell'a-capo

> "precedente del changelog, non c'è nessun problema, basta chiudere "

s/nessun/alcun/ oppure "non è un problema"

> "tenere traccia dei bug che hanno risolto secoli fa nel tuo changelog) ."

spazio prima del punto

> msgid "  * Closes: #12345, #12346, #15432\n"
> msgstr "* Closes: # 12345, # 12346, # 15432 \n"

potrebbe essere importante mantenere i due spazi iniziali
spazio finale

> msgid "Supplementing changelogs with <filename>NEWS.Debian</filename> files"
> msgstr "Integrare i changelogs con i files <filename>NEWS.Debian</filename>"

changelog
file

Io mi fermo qui con la revisione, ma ci sarebbero altre 10mila righe
in questa email!

-- 
Daniele Forsi