Capitolo 9s

[andreavaghi]

Ho iniziato a tradurre il capitolo 9s

nel terzo paragrafo dice: the file that informs Meteor of how the package should be used, and the symbols that it exports

come tradurreste symbols?

per ora ho tradotto non letteralmente: In seguito creiamo il file package.js, nel quale viene detto a Meteor come deve utilizzare il pacchetto e quali oggetti vengono esportati e resi disponibili all'applicazione

[physiocoder]

Mi sono trovato in una situazione analoga nella traduzione della documentazione ufficiale, ed anche io ho optato per "oggetti esportati" o in un caso "variabili esportate", ma ho anche mantenuto tra parentesi la dicitura (export) visto che altrove si parlava lungamente di export ed ho optato per la non traduzione ma con l'aggiunta (presente solo in italiano) di una spiegazione con perifrasi la prima volta che veniva usata.

Il giorno 19/mar/2014, alle ore 08:40, Andrea Vaghi notifications@github.com ha scritto:

Ho iniziato a tradurre il capitolo 9s

nel terzo paragrafo dice: the file that informs Meteor of how the package should be used, and the symbols that it exports

come tradurreste symbols?

per ora ho tradotto non letteralmente: In seguito creiamo il file package.js, nel quale viene detto a Meteor come deve utilizzare il pacchetto e quali oggetti vengono esportati e resi disponibili all'applicazione

— Reply to this email directly or view it on GitHub.

[jeden]

simboli suona cosi' strano? e' sorgente di ambiguita'?

il file che istruisce Meteor su come il package debba essere utilizzato, e i simboli che vengono exportati in modo da essere resi disponibili all'applicazione

[andreavaghi]

simboli è un termine che non ho mai incontrato in altri contesti, per questo motivo non lo tradurrei letteralmente. trovo che classe possa essere più chiaro per chi approccia meteor da linguaggi OO

[jeden]

a dir la verita' neanch'io - anche se raramente leggo documentazione in italiano. Cmq questa ricerca portebbe affermare il contrario.

[physiocoder]

No, vi prego, classi, fintanto che siamo in JavaScript, lo bandirei per i secoli dei secoli, altrimenti i poveri tapini che arrivano da altri linguaggi (come me, dal C++) si rompe la testa a capire perché non capisce di cosa si sta parlando… ;-)

Inoltre dire che un package rende disponibile all'esterno una classe è errato in qualsiasi paradigma OOP lo si voglia considerare (prototype based or class based).

Il giorno 19/mar/2014, alle ore 10:26, Antonio Bello notifications@github.com ha scritto:

a dir la verita' neanch'io - anche se raramente leggo documentazione in italiano. Cmq questa ricerca portebbe affermare il contrario.

— Reply to this email directly or view it on GitHub.

[andreavaghi]

perfetto. cosa ne dici di: nel quale viene detto a Meteor come deve utilizzare il pacchetto e quali simboli vengono esportati, cioè quali oggetti vengono resi disponibili all'applicazione

[jeden]

Molto meglio a mio parare.

Una possibile alternativa:

nel quale viene detto a Meteor come deve utilizzare il pacchetto e quali simboli (variabili, funzioni, etc.) vengono esportati e resi disponibili all'applicazione

[physiocoder]

Mi sembra una buona soluzione, mantiene "simboli" ed aggiunge una perifrasi per spiegare cosa sono.

Come riflessione più generale, visto che ci finiamo spesso nella discussione, aggiungo che personalmente tendo a polarizzare le mie scelte di traduzione tra:

• mantengo la parola originale ed al limite aggiungo un breve spiegazione la prima volta che la uso o un link a wikipedia italiano che spiega
• traduco, ma a quel punto mi sento libero di conservare il significato e perdere per strada la traduzione letterale, pur di usare termini comprensibili.

E' in parte una questione di stile, quindi si tratta di raggiungere un consenso, più che una ragione. Nel caso specifico avrei omesso simboli e parlato subito di cosa sono, ma anche usare simboli e spiegare cosa sono mi sembra chiaro ed efficace.

Il giorno 19/mar/2014, alle ore 10:36, Andrea Vaghi notifications@github.com ha scritto:

perfetto. cosa ne dici di: nel quale viene detto a Meteor come deve utilizzare il pacchetto e quali simboli vengono esportati, cioè quali oggetti vengono resi disponibili all'applicazione

— Reply to this email directly or view it on GitHub.

[splendido]

Concordo anch'io