Ciao Daniele, ovviamente ho incluso le tue osservazioni ma ho anche qualche domanda da porre:
1) questa frase "* Fix vsync FU w/ ancient CRTs.\n" rappresenta una voce di un file (distribuito nei pacchetti) che deve essere scritta in inglese: in questi casi si traduce? 2) spesso il testo presenta degli esempi di output (in inglese) dei programmi: sono da tradurre? 3) se penso che il testo originario sia confuso segnalo un bug con una patch al maintainer? Il giorno 20 giugno 2014 18:26, Daniele Forsi <[email protected]> ha scritto: > 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 > > > -- > Per REVOCARE l'iscrizione alla lista, inviare un email a > [email protected] con oggetto "unsubscribe". > Per > problemi inviare un email in INGLESE a [email protected] > > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: > https://lists.debian.org/can_we7pktg_su2gwxrpnzer2jgq5sb2w_h9qbvzm+yc_6g...@mail.gmail.com > >
-- principale: http://www.linux.it/tp/ ausiliaria: http://fly.cnuce.cnr.it/gnu/tp/ausiliaria.html
