Ciao a tutti oggi, un po’ di tempo fa avevo tradotto alcune parti del manuale di grass, il 6.0. Visto che comunque non era molto sentito l’argomento avevo abbandonato la cosa. Oggi ho tradotto altre parti che mi servono, riusciamo ad aggiornare la pagina sul wiki con il manuale nuovo cercando di mantenere le parti già tradotte?sempre se sono ancora valide.
On Sun, Feb 04, 2007 at 03:49:55PM +0100, Luca Delucchi wrote:
Ciao a tutti oggi, un po' di tempo fa avevo tradotto alcune parti del
manuale di grass, il 6.0. Visto che comunque non era molto sentito
l'argomento avevo abbandonato la cosa. Oggi ho tradotto altre parti che mi
servono, riusciamo ad aggiornare la pagina sul wiki con il manuale nuovo
cercando di mantenere le parti gi`a tradotte?sempre se sono ancora valide.
Negli ultimi giorni ho sistemato un po' le cose in
questo portale, ormai posso aggiungere nuove persone
nel SVN. Ma magari faccio confusione con un'altro tutorial.
Fammi sapere,
Markus
PS: I maintainer originali del SVN sono scappati via qualche
mese fa, per quello c'era silenzio dalla parte li'
Negli ultimi giorni ho sistemato un po' le cose in
questo portale, ormai posso aggiungere nuove persone
nel SVN. Ma magari faccio confusione con un'altro tutorial.
Ciao Markus,
come sai a me interessa la traduzione di quel manuale, ma qualche mese
fa mi avevi detto che non era il caso di iniziare la traduzione perché
era troppo datato e bisognava prima aspettare che venisse aggiornato a
GRASS 6.2.
La situazione è cambiata da allora? Se è possibile iniziare la
traduzione mi farebbe piacere avere un account SVN. Eventualmente ci
sentiamo in privato.
Ciao
Steko
--
Stefano Costa
Jabber: steko@jabber.linux.it http://www.iosa.it Open Archaeology
Io uso GNU/Linux!
On Mon, Feb 05, 2007 at 05:13:46PM +0100, Stefano Costa wrote:
On lun, 2007-02-05 at 15:02 +0100, Markus Neteler wrote:
> questo tutorial:
> http://www.gdf-hannover.de/literatur
> ?
>
> Negli ultimi giorni ho sistemato un po' le cose in
> questo portale, ormai posso aggiungere nuove persone
> nel SVN. Ma magari faccio confusione con un'altro tutorial.
Ciao Markus,
come sai a me interessa la traduzione di quel manuale, ma qualche mese
fa mi avevi detto che non era il caso di iniziare la traduzione perché
era troppo datato e bisognava prima aspettare che venisse aggiornato a
GRASS 6.2.
La situazione è cambiata da allora?
Si' e no
Rimane valido la situazione che bisogna aggiornare il tutorial su 6.2.
Ma i colleghi della GDF mi hanno promesso di lavorare su.
Se è possibile iniziare la
traduzione mi farebbe piacere avere un account SVN. Eventualmente ci
sentiamo in privato.
Va bene... almeno l'idea & tutorial vivono ancora!
ciao
Markus
Ciao
Steko
--
Stefano Costa
Jabber: steko@jabber.linux.it http://www.iosa.it Open Archaeology
Io uso GNU/Linux!
Negli ultimi giorni ho sistemato un po’ le cose in
questo portale, ormai posso aggiungere nuove persone
nel SVN. Ma magari faccio confusione con un’altro tutorial.
Ciao Markus,
come sai a me interessa la traduzione di quel manuale, ma qualche mese
fa mi avevi detto che non era il caso di iniziare la traduzione perché
era troppo datato e bisognava prima aspettare che venisse aggiornato a
GRASS 6.2.
La situazione è cambiata da allora?
Si’ e no
Rimane valido la situazione che bisogna aggiornare il tutorial su 6.2.
Ma i colleghi della GDF mi hanno promesso di lavorare su.
Se è possibile iniziare la
traduzione mi farebbe piacere avere un account SVN. Eventualmente ci
sentiamo in privato.
Va bene… almeno l’idea & tutorial vivono ancora!
Anche a me farebbe piacere fare la traduzione, poichè mi sembra un ottimo modo per imparare ad usare grass in modo ottimale. Potremmo organizzarci e mettere su un gruppetto di persone che ci lavorino.
Per tradurre quasi completamente il manuale di QGIS non c'è voluto molto.
GRASS è più ostico ma una frase oggi una frase domani e presto il gioco è fatto.
il sistema tramite wiki permette a più persone di diventare rapidamente editor e di aggiornare o migliorare le pagine.
per chi si aggiunge c'è sempre la possibilità di seguire lo storico di ogni pagina e capire se sono stati fatti degli errori e in tal caso intervenire.
E' anche un ottimo modo per imparare i comandi...
Markus Neteler ha scritto:
> On Mon, Feb 05, 2007 at 05:13:46PM +0100, Stefano Costa wrote:
>> Se ? possibile iniziare la
>> traduzione mi farebbe piacere avere un account SVN. Eventualmente ci
>> sentiamo in privato.
>
> Va bene... almeno l'idea & tutorial vivono ancora!
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
Ciao Lorenzo,
sono perfettamente d'accordo, ma proprio perché il vostro è stato un
lavoro ottimo e importante, non posso evitare di notare che l'esistenza
di questa documentazione tradotta è praticamente sconosciuta, anzitutto
ai team di sviluppo dei programmi:
(e la mia risposta che segue). Questo non mi sembra buono, perché
significa non valorizzare tutto il tempo che ci avete dedicato e
continuerete a dedicarci.
Stessa cosa vale per GRASS: perché non si studia un modo (semplice..)
per integrare quella traduzione all'interno delle pagine di manuale del
programma, piuttosto che lasciarle solo sul wiki?
Continuo a pensare che la traduzione di applicazioni e documentazione
sia una delle cose più importanti in assoluto.
Ciao,
Steko
--
Stefano Costa
Jabber: steko@jabber.linux.it http://www.iosa.it Open Archaeology
Io uso GNU/Linux!
Per tradurre quasi completamente il manuale di QGIS non c’è voluto molto.
GRASS è più ostico ma una frase oggi una frase domani e presto il gioco
è fatto.
Io e una ragazza abbiamo tradotto già alcune parti e inserite nel wiki.
il sistema tramite wiki permette a più persone di diventare rapidamente
editor e di aggiornare o migliorare le pagine.
per chi si aggiunge c’è sempre la possibilità di seguire lo storico di
ogni pagina e capire se sono stati fatti degli errori e in tal caso
intervenire.
E’ anche un ottimo modo per imparare i comandi…
Noi abbiamo trovato due problemi principali con questo approccio:
- - la conversione in un formato utilizzabile (tipicamente pdf) non e'
liscia e pulita
- - la sincronizzazione con i cambiamenti upstream e' una grossa sofferenza
L'altro approccio (latex+svn) risolve brillantemente questi due
problemi, ma ha una soglia d'ingresso che tiene lontani molti utenti.
Ancora non abbiamo trovato una soluzione brillante. Ci fosse, sono
sicuro che le traduzioni andrebbero *molto* piu' spedite ed efficienti.
pc
Il 08:41, martedì 6 febbraio 2007, Paolo Cavallini ha scritto:
Noi abbiamo trovato due problemi principali con questo approccio:
- la conversione in un formato utilizzabile (tipicamente pdf) non e'
liscia e pulita
- la sincronizzazione con i cambiamenti upstream e' una grossa sofferenza
L'altro approccio (latex+svn) risolve brillantemente questi due
problemi, ma ha una soglia d'ingresso che tiene lontani molti utenti.
Ancora non abbiamo trovato una soluzione brillante. Ci fosse, sono
sicuro che le traduzioni andrebbero *molto* piu' spedite ed efficienti.
pc
Nel gruppo di traduzione KDE usiamo docbook, c'è un tool che trasforma i
diversi pezzi del docbook di un programma in gruppi di messaggi gettext (PO)
e questi vengono poi assegnati ai diversi traduttori.
Non mancano i tool specializzati per tradurre (kbabel e poedit).
Credo che il setup del sistema sia piuttosto laborioso, ma poi il lavoro va
via spedito.
Credo che anche gnome usi un sistema simile.
Il tutto è in SVN e i tool per i PO mantengono le vecchie traduzioni segnando
come fuzzy le traduzioni modificate.
Ciao
--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502
se si passa dalla traduzione di interfacce alla traduzione di documenti POedit potrebbe non essere la soluzione migliore.
esistono altri ambienti opensource per gestire documentazione tecnica.
ad es. OmegaT funziona, e credo possa utilizzare anche dati source in latex…vedi: http://sourceforge.net/projects/omegat
fatemi sapere se volete che mi interessi, per capire meglio, o se c’è qualcun altro che già conosce lo strumento e può fare una prova.
se invece sapete di alternative migliori, o avete già “sbattuto le corna” su problemi con OmegaT, sarei interessato a capire meglio in quale contesto lo avete usato, dato che lo sto valutando assieme ad altri prodotti simili.
Il 08:41, martedì 6 febbraio 2007, Paolo Cavallini ha scritto:
Noi abbiamo trovato due problemi principali con questo approccio:
la conversione in un formato utilizzabile (tipicamente pdf) non e’
liscia e pulita
la sincronizzazione con i cambiamenti upstream e’ una grossa sofferenza
L’altro approccio (latex+svn) risolve brillantemente questi due
problemi, ma ha una soglia d’ingresso che tiene lontani molti utenti.
Ancora non abbiamo trovato una soluzione brillante. Ci fosse, sono
sicuro che le traduzioni andrebbero molto piu’ spedite ed efficienti.
pc
Nel gruppo di traduzione KDE usiamo docbook, c’è un tool che trasforma i
diversi pezzi del docbook di un programma in gruppi di messaggi gettext (PO)
e questi vengono poi assegnati ai diversi traduttori.
Non mancano i tool specializzati per tradurre (kbabel e poedit).
Credo che il setup del sistema sia piuttosto laborioso, ma poi il lavoro va
via spedito.
Credo che anche gnome usi un sistema simile.
Il tutto è in SVN e i tool per i PO mantengono le vecchie traduzioni segnando
come fuzzy le traduzioni modificate.
Ciao
Alessandro Pasotti
itOpen - “Open Solutions for the Net Age”
w3: www.itopen.it
Linux User# 167502
On Mon, Feb 05, 2007 at 10:31:00PM +0100, Stefano Costa wrote:
...
Stessa cosa vale per GRASS: perché non si studia un modo (semplice..)
per integrare quella traduzione all'interno delle pagine di manuale del
programma, piuttosto che lasciarle solo sul wiki?
Bravo! Serve la traduzione delle pagine HTML, in una
cartella aparte. Probabilmente servono solo un paio di
modifiche piccole in include/Make/Html.make
sono perfettamente d'accordo, ma proprio perché il vostro è stato un
lavoro ottimo e importante, non posso evitare di notare che l'esistenza
di questa documentazione tradotta è praticamente sconosciuta, anzitutto
ai team di sviluppo dei programmi:
(e la mia risposta che segue). Questo non mi sembra buono, perché
significa non valorizzare tutto il tempo che ci avete dedicato e
continuerete a dedicarci.
I testi che sono uguali da una versione all'altra di una guida sono sempre tanti e basta fare un copia e incolla.
Così si può mantenere in parallelo lo storico delle varie versioni.
Io posso contribuire a delle traduzioni ma non voglio certo installarmi un programma per questo.
La traduzione di una pagina può essere fatta al volo. Es: la cerchi su google, trovi una traduzione non completa, capisci di che si parla, clicchi su "edit" e finisci il lavoro fatto da altri usando il tuo browser preferito. Avete alternarive più comode?
Se i vecchi sistemi non hanno dilagato è perchè sono scomodi non perchè le persone non vogliano contribuire.
Invece di fare le parole crociate apro il mio browser e mi traduco due righe su wiki, tanto per rilassarmi.
Per le versioni PDF non dev'essere difficile fare uno script che catturi solo le pagine di una data categoria. A me non serve e non lo scrivo ma chi è interessato può anche farselo.
On Tue, Feb 06, 2007 at 08:41:43AM +0100, Paolo Cavallini wrote:
- - la sincronizzazione con i cambiamenti upstream e' una grossa sofferenza
L'altro approccio (latex+svn) risolve brillantemente questi due
problemi, ma ha una soglia d'ingresso che tiene lontani molti utenti.
Ancora non abbiamo trovato una soluzione brillante. Ci fosse, sono
sicuro che le traduzioni andrebbero *molto* piu' spedite ed efficienti.
Just my 2 cents...
svn non e' lo strumento piu' efficace per sincronizzare i tree di
traduzione, meglio cvs. Il motivo e' presto detto: in cvs si mantengono
numeri di versione diversi per ciascun file, in svn no. La
tracciabilita' delle modifiche e' di molto facilitata: il problema
e che dato un file tradotto non si sa quale versione del tree
originale traduce e quindi si e' belli che fottuti. Si puo'
aggingere a mano la release svn di riferimento (in un commento), ma
tale release e' di fatto relativa all'intero tree e quindi ci si
fa non molto, perche' cambia anche quando il file di riferimento
relativo non cambia: occorre farsi il diff a mano e verificare
se ci sono modifiche.
In ogni caso, suggerisco di aggiungere l'apposito campo: es.
% X-Translation-Reference: r1245
Questo nella ipotesi di implementare appositi script di check.
Il campo va aggiornato ogni volta che si aggiorna la traduzione
ovviamente. Senza tale accorgimento, siete nella cacca Con
tale versione, almeno si sa da dove cominciare a guardarsi i diff
del tree da tradurre.
PS:
Di qui anche il fatto che usare un wiki per le traduzioni e' una nuova
forma raffinata di tortura IMHO, spiacente Lorenzo
PS:
Di qui anche il fatto che usare un wiki per le traduzioni e' una nuova
forma raffinata di tortura IMHO, spiacente Lorenzo
Che qui siamo tutti masochisti non credo che ci sia dubbio alcuno.
In quanti, di quelli che fanno qualcosa per la comunità, si sono passati una domenica a scrivere how to, traduzioni, studiare software, ecc. ?
non era meglio farsi una scampagnata?
Attualmente ci sono 6-7 persone che, con impegno variabile, stanno collaborando alla prima traduzione.
ora io so che hai delle buone idee su come raffinare la cosa.
E' importante riuscire a taggare le release della documentazione così da poter fare delle dif e non dover andare a guardare riga per riga cosa è cambiato.
rilanci?
noi per ora, come "anno 0", abbiamo la versione attualmente online (6.0.2) http://grass.itc.it/grass60/manuals/html60_user/
il cui mime ci dice che non è stata toccata dal:
Last-Modified: Tue, 28 Feb 2006 10:03:43 GMT
On Wed, Feb 28, 2007 at 01:39:09PM +0100, Lorenzo Becchi wrote:
> PS:
> Di qui anche il fatto che usare un wiki per le traduzioni e' una nuova
> forma raffinata di tortura IMHO, spiacente Lorenzo
Che qui siamo tutti masochisti non credo che ci sia dubbio alcuno.
In quanti, di quelli che fanno qualcosa per la comunità, si sono passati
una domenica a scrivere how to, traduzioni, studiare software, ecc. ?
non era meglio farsi una scampagnata?
Attualmente ci sono 6-7 persone che, con impegno variabile, stanno
collaborando alla prima traduzione.
ora io so che hai delle buone idee su come raffinare la cosa.
E' importante riuscire a taggare le release della documentazione così da
poter fare delle dif e non dover andare a guardare riga per riga cosa è
cambiato.
rilanci?
noi per ora, come "anno 0", abbiamo la versione attualmente online (6.0.2) http://grass.itc.it/grass60/manuals/html60_user/
il cui mime ci dice che non è stata toccata dal:
Last-Modified: Tue, 28 Feb 2006 10:03:43 GMT
Ne abbiamo parlato via irc, si tratta di mirrorare lo snapshot della
doc originale di grass (daily?) su
Usando tale copia mirrorata si possono aggiornare e committare (ehm)
le copie dei singoli file su un repository cvs, taggare di conseguenza
con un apposito timestamp (per esempio la data di commit) e far riferimento
a tale tag ogni volta che si mette mano alla traduzione (inserendolo come
campo obbligatorio di commento nel wiki di traduzione). Usando
il repository cvs (via cvsweb per esempio, che e' di facile uso)
si puo' poi guardare cosa cambia nella documentazione originale
tra un tag e l'altro e tradurre solo tali parti.
La cosa semplificherebbe notevolmente l'opera di traduzione,
perche' i traduttori potrebbero mettere mano alle sole parti
cambiate anche a distanza di tempo.
On Wed, Feb 28, 2007 at 01:39:09PM +0100, Lorenzo Becchi wrote:
noi per ora, come "anno 0", abbiamo la versione attualmente online (6.0.2) http://grass.itc.it/grass60/manuals/html60_user/
il cui mime ci dice che non è stata toccata dal:
Last-Modified: Tue, 28 Feb 2006 10:03:43 GMT
Questo credo sia legato al fatto che la doc viene rigenerata tutti
i giorni. Markus?