Nuove stringhe da tradurre per LibreOffice 3.5 e metodo di lavoro

> Ciao a tutti,
>
> si aprono le traduzioni delle  nuove stringhe di Libreoffice per la
> nuova versione in uscita (3.5) a dicembre.
>
> Lo string freeze è previsto il 19 dicembre, quindi abbiamo un mesetto
> buono per lavorarci sopra, tenuto conto che le stringhe potranno anche
> essere aggiornate.
>
> Chi vuole collaborare si faccia pure avanti senza indugio! Le/gli
> verranno assegnati dei pacchetti da tradurre che dovranno essere
> restituiti al sottoscritto. provvederò io, al momento, al caricamento
> in Pootle.
>
> Lamento fin d'ora la mancanza di Paolo (Pozzan) alla guida del
> processo di traduzione, il quale ha deciso di seguire nuove strade ed
> esperienze. Paolo, noi siamo qui!
>
> Andrea, tu hai tempo per collaborare come coordinatore ed,
> eventualmente, come revisore?
>
> Di seguito un ipotetico metodo di lavoro da seguire. Mi scuso per la
> lunghezza del post.
>
> *Premessa*
>
> Fino ad adesso, per adesso intendo per OpenOffice.org, il metodo era:
>
> - estrapolazione delle stringhe da tradurre dai pacchetti
> - assegnazione delle stringhe ai vari traduttori
> - traduzione offline con CAT tool, (era stato adottato OmegaT, come
> strumento preferito)
> - rinvio delle stringhe tradotte
> - revisione
> - ricostruzione dei file e caricamento sul server
>
> A mio personalissimo avviso, questo metodo non era completamente
> efficace per una serie di motivi, tra cui:
>
> - spesso le stringhe erano avulse dal contesto del pacchetto di
> stringhe che le ospitava, ed era (non è comunque) meno facile capirne
> il senso
> - lo strumento utilizzato (OmegaT) era, ed è, un ottimo strumento di
> traduzione, ma non totalmente adatto alla gestione di file .po su cui
> si lavora. In particolare perché non gestisce bene la varietà di
> significati che una parola inglese può assumere nella lingua italiana;
> in parole povere, la traduzione di una parola è univoca e si riproduce
> a cascata su tutte le altre uguali, creando non pochi errori (un
> esempio: "downloaded" può significare "scaricato, scaricati,
> scaricata, scaricate", dipende dal contesto; con OmegaT, se si traduce
> in _scaricato_, tutte le occorrenze "singole" di downloaded vengono
> tradotte così, creando incongruenze)
> - la revisione e la ricostruzione dei file poteva essere difficoltosa,
> dispendiosa di tempo e con errori
>
> *Nuovo metodo suggerito*
>
> - adozione di nuovi strumenti CAT a scelta, ma che gestisca in modo
> omogeneo i file .po/.pot; per ciò che mi riguarda, lavorando in
> ambiente KDE, uso Lokalize che funziona egregiamente. Per Windows, Mac
> e Linux Gnome/XCFE/LDXE *POEdit* (http://www.poedit.net) dovrebbe
> essere una soluzione più che adatta. Se qualcuno ne ha altri che
> gestiscono bene questo tipo di file, ben venga!
> - assegnazione ad ogni singolo traduttore di un file singolo completo
> e relativo corrispondente della guida, se esistente, al fine di
> permettere un lavoro più omogeneo e razionale e di avere una visione
> generale del pacchetto di stringhe su cui ci si muove. Naturalmente
> qualche file sarà più lungo degli altri, ma sarà possibile lavorare
> "dalla stringa xxx alla stringa yyy" (per i file molto grossi, che al
> momento non noto), assegnando uno stesso file a più traduttori.
> - le parti tradotte vanno restituite "da approvare" (fuzzy) per una
> facile e rapida individuazione (sarà compito del revisore approvare le
> traduzioni)
> - restituzione dei file tradotti al revisore, revisori (spero di non
> essere da solo... Andrea? Luca?)
> - controllo e caricamento in Pootle (da parte del sottoscritto)
>
> I *vantaggi*:
>
> - il traduttore ha la panoramica completa dell'area in cui opera,
> compresa la guida, quindi una migliore comprensione del "tutto"
> - il file tradotto è già pronto, va solo controllato, eventualmente
> corretto e caricato
> - si saltano passaggi di unione e riconversione, con rischio di
> perdita di dati e/o stringhe
>
> Se dovessero servire memorie di traduzione, non è un problema, oltre
> quelle già esistenti, è possibile, da Lokalize, per esempio, creare ed
> esportare/importare memorie (.tmx) da un intero progetto di
> traduzione. Inoltre è possibile avere traduzioni alternative per
> tenere sott'occhio le traduzioni dei colleghi "stranieri", al fine di
> avere suggerimenti utili. Pootle già offre questa possibilità, basta
> solo scaricare i pacchetti e configurare il programma CAT per leggere
> quei file.
>
> Tutta questa lungaggine a parole, tra l'altro, è molto più semplice a
> farsi che a dirsi, quindi non ci si spaventi per l'inizio, siamo qui
> per aiutare e consigliare (naturalmente c'è gente più esperta di me
> che può farlo... :)
>
> L'importante è seguire le regole di traduzione, che sono poi le stesse
> che si utilizzavano quando si traduceva OpenOffice.org
>
> Naturalmente questa è la mia visione del processo di traduzione,
> ognuno è libero di agire come preferisce e suggerire un proprio
> metodo. Sarebbe possibile lavorare in direttamente in Pootle, ma per
> far quello bisogna essere esperti e sapere cosa si sta toccando e
> modificando. Gli errori sono sempre in agguato ed è un attimo
> sbagliare. Lo dico per comprovata esperienza, di errori ne ho commesso
> e ne commetto tantissimi anch'io.
>
> Dunque, per concludere, suggerimenti e altri metodi sono bene accetti,
> fermo restando il fatto che la base su cui lavorare sarà comunque
> Pootle, che viene di volta in volta aggiornato dai responsabili dei
> pacchetti di lingua (nello specifico Andras Timar, se non erro).
>
> Chi ha intenzione di collaborare, questo è il momento giusto! Fatevi
> avanti senza indugio!!!
>
> Ciao!

> Ciao a tutti,
>
> si aprono le traduzioni delle  nuove stringhe di Libreoffice per la
> nuova versione in uscita (3.5) a dicembre.
>
> Lo string freeze è previsto il 19 dicembre, quindi abbiamo un mesetto
> buono per lavorarci sopra, tenuto conto che le stringhe potranno anche
> essere aggiornate.
>
> Chi vuole collaborare si faccia pure avanti senza indugio! Le/gli
> verranno assegnati dei pacchetti da tradurre che dovranno essere
> restituiti al sottoscritto. provvederò io, al momento, al caricamento in
> Pootle.
>
> Lamento fin d'ora la mancanza di Paolo (Pozzan) alla guida del processo
> di traduzione, il quale ha deciso di seguire nuove strade ed esperienze.
> Paolo, noi siamo qui!
>
> Andrea, tu hai tempo per collaborare come coordinatore ed,
> eventualmente, come revisore?
>
> Di seguito un ipotetico metodo di lavoro da seguire. Mi scuso per la
> lunghezza del post.
>
> *Premessa*
>
> Fino ad adesso, per adesso intendo per OpenOffice.org, il metodo era:
>
> - estrapolazione delle stringhe da tradurre dai pacchetti
> - assegnazione delle stringhe ai vari traduttori
> - traduzione offline con CAT tool, (era stato adottato OmegaT, come
> strumento preferito)
> - rinvio delle stringhe tradotte
> - revisione
> - ricostruzione dei file e caricamento sul server
>
> A mio personalissimo avviso, questo metodo non era completamente
> efficace per una serie di motivi, tra cui:
>
> - spesso le stringhe erano avulse dal contesto del pacchetto di stringhe
> che le ospitava, ed era (non è comunque) meno facile capirne il senso
> - lo strumento utilizzato (OmegaT) era, ed è, un ottimo strumento di
> traduzione, ma non totalmente adatto alla gestione di file .po su cui si
> lavora. In particolare perché non gestisce bene la varietà di
> significati che una parola inglese può assumere nella lingua italiana;
> in parole povere, la traduzione di una parola è univoca e si riproduce a
> cascata su tutte le altre uguali, creando non pochi errori (un esempio:
> "downloaded" può significare "scaricato, scaricati, scaricata,
> scaricate", dipende dal contesto; con OmegaT, se si traduce in
> _scaricato_, tutte le occorrenze "singole" di downloaded vengono
> tradotte così, creando incongruenze)
> - la revisione e la ricostruzione dei file poteva essere difficoltosa,
> dispendiosa di tempo e con errori
>
> *Nuovo metodo suggerito*
>
> - adozione di nuovi strumenti CAT a scelta, ma che gestisca in modo
> omogeneo i file .po/.pot; per ciò che mi riguarda, lavorando in ambiente
> KDE, uso Lokalize che funziona egregiamente. Per Windows, Mac e Linux
> Gnome/XCFE/LDXE *POEdit* (http://www.poedit.net) dovrebbe essere una
> soluzione più che adatta. Se qualcuno ne ha altri che gestiscono bene
> questo tipo di file, ben venga!
> - assegnazione ad ogni singolo traduttore di un file singolo completo e
> relativo corrispondente della guida, se esistente, al fine di permettere
> un lavoro più omogeneo e razionale e di avere una visione generale del
> pacchetto di stringhe su cui ci si muove. Naturalmente qualche file sarà
> più lungo degli altri, ma sarà possibile lavorare "dalla stringa xxx
> alla stringa yyy" (per i file molto grossi, che al momento non noto),
> assegnando uno stesso file a più traduttori.
> - le parti tradotte vanno restituite "da approvare" (fuzzy) per una
> facile e rapida individuazione (sarà compito del revisore approvare le
> traduzioni)
> - restituzione dei file tradotti al revisore, revisori (spero di non
> essere da solo... Andrea? Luca?)
> - controllo e caricamento in Pootle (da parte del sottoscritto)
>
> I *vantaggi*:
>
> - il traduttore ha la panoramica completa dell'area in cui opera,
> compresa la guida, quindi una migliore comprensione del "tutto"
> - il file tradotto è già pronto, va solo controllato, eventualmente
> corretto e caricato
> - si saltano passaggi di unione e riconversione, con rischio di perdita
> di dati e/o stringhe
>
> Se dovessero servire memorie di traduzione, non è un problema, oltre
> quelle già esistenti, è possibile, da Lokalize, per esempio, creare ed
> esportare/importare memorie (.tmx) da un intero progetto di traduzione.
> Inoltre è possibile avere traduzioni alternative per tenere sott'occhio
> le traduzioni dei colleghi "stranieri", al fine di avere suggerimenti
> utili. Pootle già offre questa possibilità, basta solo scaricare i
> pacchetti e configurare il programma CAT per leggere quei file.
>
> Tutta questa lungaggine a parole, tra l'altro, è molto più semplice a
> farsi che a dirsi, quindi non ci si spaventi per l'inizio, siamo qui per
> aiutare e consigliare (naturalmente c'è gente più esperta di me che può
> farlo... :)
>
> L'importante è seguire le regole di traduzione, che sono poi le stesse
> che si utilizzavano quando si traduceva OpenOffice.org
>
> Naturalmente questa è la mia visione del processo di traduzione, ognuno
> è libero di agire come preferisce e suggerire un proprio metodo. Sarebbe
> possibile lavorare in direttamente in Pootle, ma per far quello bisogna
> essere esperti e sapere cosa si sta toccando e modificando. Gli errori
> sono sempre in agguato ed è un attimo sbagliare. Lo dico per comprovata
> esperienza, di errori ne ho commesso e ne commetto tantissimi anch'io.
>
> Dunque, per concludere, suggerimenti e altri metodi sono bene accetti,
> fermo restando il fatto che la base su cui lavorare sarà comunque
> Pootle, che viene di volta in volta aggiornato dai responsabili dei
> pacchetti di lingua (nello specifico Andras Timar, se non erro).
>
> Chi ha intenzione di collaborare, questo è il momento giusto! Fatevi
> avanti senza indugio!!!
>
> Ciao!
> --
> Valter
> *Open Source is better!*
> KDE: www.kde.org
> Kubuntu: www.kubuntu.org
> LibreOffice: www.libreoffice.org
>

> Ciao a tutti,
>
> si aprono le traduzioni delle  nuove stringhe di Libreoffice per la
> nuova versione in uscita (3.5) a dicembre.
>
> Lo string freeze è previsto il 19 dicembre, quindi abbiamo un mesetto
> buono per lavorarci sopra, tenuto conto che le stringhe potranno anche
> essere aggiornate.
>
> Chi vuole collaborare si faccia pure avanti senza indugio! Le/gli
> verranno assegnati dei pacchetti da tradurre che dovranno essere
> restituiti al sottoscritto. provvederò io, al momento, al caricamento
> in Pootle.
>

> Il 01/11/2011 10:35, Valter Mura ha scritto:
>> Ciao a tutti,
>>
>> si aprono le traduzioni delle nuove stringhe di Libreoffice per la
>> nuova versione in uscita (3.5) a dicembre.
>>
>> Lo string freeze è previsto il 19 dicembre, quindi abbiamo un mesetto
>> buono per lavorarci sopra, tenuto conto che le stringhe potranno anche
>> essere aggiornate.
>>
>> Chi vuole collaborare si faccia pure avanti senza indugio! Le/gli
>> verranno assegnati dei pacchetti da tradurre che dovranno essere
>> restituiti al sottoscritto. provvederò io, al momento, al caricamento
>> in Pootle.
>>
> Ciao,
> Anche io ci sono per un file di piccole dimensioni, giusto per usare un
> editor po, che non ho ancora mai utilizzato.
> Ciao! :)
>

> Ciao a tutti,
>
> si aprono le traduzioni delle  nuove stringhe di Libreoffice per la
> nuova versione in uscita (3.5) a dicembre.
>
> Lo string freeze è previsto il 19 dicembre, quindi abbiamo un mesetto
> buono per lavorarci sopra, tenuto conto che le stringhe potranno anche
> essere aggiornate.
>
> Chi vuole collaborare si faccia pure avanti senza indugio! Le/gli
> verranno assegnati dei pacchetti da tradurre che dovranno essere
> restituiti al sottoscritto. provvederò io, al momento, al caricamento
> in Pootle.
>
> Lamento fin d'ora la mancanza di Paolo (Pozzan) alla guida del
> processo di traduzione, il quale ha deciso di seguire nuove strade ed
> esperienze. Paolo, noi siamo qui!
>
> Andrea, tu hai tempo per collaborare come coordinatore ed,
> eventualmente, come revisore?
>
> Di seguito un ipotetico metodo di lavoro da seguire. Mi scuso per la
> lunghezza del post.
>
> *Premessa*
>
> Fino ad adesso, per adesso intendo per OpenOffice.org, il metodo era:
>
> - estrapolazione delle stringhe da tradurre dai pacchetti
> - assegnazione delle stringhe ai vari traduttori
> - traduzione offline con CAT tool, (era stato adottato OmegaT, come
> strumento preferito)
> - rinvio delle stringhe tradotte
> - revisione
> - ricostruzione dei file e caricamento sul server
>
> A mio personalissimo avviso, questo metodo non era completamente
> efficace per una serie di motivi, tra cui:
>
> - spesso le stringhe erano avulse dal contesto del pacchetto di
> stringhe che le ospitava, ed era (non è comunque) meno facile capirne
> il senso
> - lo strumento utilizzato (OmegaT) era, ed è, un ottimo strumento di
> traduzione, ma non totalmente adatto alla gestione di file .po su cui
> si lavora. In particolare perché non gestisce bene la varietà di
> significati che una parola inglese può assumere nella lingua italiana;
> in parole povere, la traduzione di una parola è univoca e si riproduce
> a cascata su tutte le altre uguali, creando non pochi errori (un
> esempio: "downloaded" può significare "scaricato, scaricati,
> scaricata, scaricate", dipende dal contesto; con OmegaT, se si traduce
> in _scaricato_, tutte le occorrenze "singole" di downloaded vengono
> tradotte così, creando incongruenze)
> - la revisione e la ricostruzione dei file poteva essere difficoltosa,
> dispendiosa di tempo e con errori
>
> *Nuovo metodo suggerito*
>
> - adozione di nuovi strumenti CAT a scelta, ma che gestisca in modo
> omogeneo i file .po/.pot; per ciò che mi riguarda, lavorando in
> ambiente KDE, uso Lokalize che funziona egregiamente. Per Windows, Mac
> e Linux Gnome/XCFE/LDXE *POEdit* (http://www.poedit.net) dovrebbe
> essere una soluzione più che adatta. Se qualcuno ne ha altri che
> gestiscono bene questo tipo di file, ben venga!
> - assegnazione ad ogni singolo traduttore di un file singolo completo
> e relativo corrispondente della guida, se esistente, al fine di
> permettere un lavoro più omogeneo e razionale e di avere una visione
> generale del pacchetto di stringhe su cui ci si muove. Naturalmente
> qualche file sarà più lungo degli altri, ma sarà possibile lavorare
> "dalla stringa xxx alla stringa yyy" (per i file molto grossi, che al
> momento non noto), assegnando uno stesso file a più traduttori.
> - le parti tradotte vanno restituite "da approvare" (fuzzy) per una
> facile e rapida individuazione (sarà compito del revisore approvare le
> traduzioni)
> - restituzione dei file tradotti al revisore, revisori (spero di non
> essere da solo... Andrea? Luca?)
> - controllo e caricamento in Pootle (da parte del sottoscritto)
>
> I *vantaggi*:
>
> - il traduttore ha la panoramica completa dell'area in cui opera,
> compresa la guida, quindi una migliore comprensione del "tutto"
> - il file tradotto è già pronto, va solo controllato, eventualmente
> corretto e caricato
> - si saltano passaggi di unione e riconversione, con rischio di
> perdita di dati e/o stringhe
>
> Se dovessero servire memorie di traduzione, non è un problema, oltre
> quelle già esistenti, è possibile, da Lokalize, per esempio, creare ed
> esportare/importare memorie (.tmx) da un intero progetto di
> traduzione. Inoltre è possibile avere traduzioni alternative per
> tenere sott'occhio le traduzioni dei colleghi "stranieri", al fine di
> avere suggerimenti utili. Pootle già offre questa possibilità, basta
> solo scaricare i pacchetti e configurare il programma CAT per leggere
> quei file.
>
> Tutta questa lungaggine a parole, tra l'altro, è molto più semplice a
> farsi che a dirsi, quindi non ci si spaventi per l'inizio, siamo qui
> per aiutare e consigliare (naturalmente c'è gente più esperta di me
> che può farlo... :)
>
> L'importante è seguire le regole di traduzione, che sono poi le stesse
> che si utilizzavano quando si traduceva OpenOffice.org
>
> Naturalmente questa è la mia visione del processo di traduzione,
> ognuno è libero di agire come preferisce e suggerire un proprio
> metodo. Sarebbe possibile lavorare in direttamente in Pootle, ma per
> far quello bisogna essere esperti e sapere cosa si sta toccando e
> modificando. Gli errori sono sempre in agguato ed è un attimo
> sbagliare. Lo dico per comprovata esperienza, di errori ne ho commesso
> e ne commetto tantissimi anch'io.
>
> Dunque, per concludere, suggerimenti e altri metodi sono bene accetti,
> fermo restando il fatto che la base su cui lavorare sarà comunque
> Pootle, che viene di volta in volta aggiornato dai responsabili dei
> pacchetti di lingua (nello specifico Andras Timar, se non erro).
>
> Chi ha intenzione di collaborare, questo è il momento giusto! Fatevi
> avanti senza indugio!!!
>
> Ciao!

> Il 04/12/2011 23:11, Valter Mura ha scritto:
>
>> ma che attendiamo il 19 dicembre per iniziare le traduzioni, dato che
>> quella è la data di blocco (in teoria) delle stringhe da tradurre.
>>
>
> Siamo al 21 dicembre. si sa nulla delle stringhe da tradurre? come
> verranno assegnate, o come richiederne l'assegnazione?
>
> Attendo istruzioni.
>
> Lorenzo
>
>
> --
> /possono dirci su che cosa riflettere, non che cosa pensare/
>
> --
> Come cancellarsi: E-mail [hidden email]
> Problemi? http://it.libreoffice.org/**supporto/mailing-lists/come-**
> cancellarsi/<http://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/>
> Linee guida per postare + altro: http://wiki.**documentfoundation.org/**
> Netiquette <http://wiki.documentfoundation.org/Netiquette>
> Archivio della lista: http://listarchives.**libreoffice.org/it/l10n/<http://listarchives.libreoffice.org/it/l10n/>
> Tutti i messaggi inviati a questa lista vengono archiviati pubblicamente e
> non sono eliminabili
>
>

> Il 04/12/2011 23:11, Valter Mura ha scritto:
>
>> ma che attendiamo il 19 dicembre per iniziare le traduzioni, dato che
>> quella è la data di blocco (in teoria) delle stringhe da tradurre.
>>
>
> Siamo al 21 dicembre. si sa nulla delle stringhe da tradurre? come
> verranno assegnate, o come richiederne l'assegnazione?
>
> Attendo istruzioni.
>
> Lorenzo
>
>
> --
> /possono dirci su che cosa riflettere, non che cosa pensare/
>
> --
> Come cancellarsi: E-mail [hidden email]
> Problemi? http://it.libreoffice.org/**supporto/mailing-lists/come-**
> cancellarsi/<http://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/>
> Linee guida per postare + altro: http://wiki.**documentfoundation.org/**
> Netiquette <http://wiki.documentfoundation.org/Netiquette>
> Archivio della lista:
> http://listarchives.**libreoffice.org/it/l10n/<http://listarchives.libreoffice.org/it/l10n/>
> Tutti i messaggi inviati a questa lista vengono archiviati pubblicamente e
> non sono eliminabili
>
>

> Il 21/12/2011 Valter Mura ha scritto:
>> fra qualche giorno vi aggiornerò sul da farsi.
>
> Se qualcun altro e' in attesa di notizie, io ho fatto un po' di prove
> con gli strumenti e le procedure che suggeriva Valter e funziona tutto.
>
> Le stringhe sono semidefinitive ma non ancora definitive al 100%, vedete
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb
>
> (se ne capite appena di codice, vedrete che ridefinisce le stringhe
> inglesi "Insert Rows" e "Insert Columns" in modo che siano indipendenti
> perche' necessario per tradurle in alcune lingue; e' di oggi).
>
> Il volume di traduzioni e' stimabile in circa 4000 parole sia per la
> guida sia per l'interfaccia utente; queste ultime sembrano molte, ma ad
> esempio 600 sono in stringhe del tipo "Correttore ortografico e
> dizionario dei sinonimi per la lingua Italiana/Francese/..." e 600 sono
> legate al fatto che il risolutore non-lineare di Sun/Oracle sembra
> essere stato spostato nel ramo principale dei sorgenti.
>
> Si tratta di un volume gestibile senza particolari difficolta'.

> Il 01/01/2012 18:49, Andrea Pescetti ha scritto:
>
> > Il 21/12/2011 Valter Mura ha scritto:
> >> fra qualche giorno vi aggiornerò sul da farsi.
> >
> > Se qualcun altro e' in attesa di notizie, io ho fatto un po' di prove
> > con gli strumenti e le procedure che suggeriva Valter e funziona tutto.
> >
> > Le stringhe sono semidefinitive ma non ancora definitive al 100%, vedete
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb
> >
> > (se ne capite appena di codice, vedrete che ridefinisce le stringhe
> > inglesi "Insert Rows" e "Insert Columns" in modo che siano indipendenti
> > perche' necessario per tradurle in alcune lingue; e' di oggi).
> >
> > Il volume di traduzioni e' stimabile in circa 4000 parole sia per la
> > guida sia per l'interfaccia utente; queste ultime sembrano molte, ma ad
> > esempio 600 sono in stringhe del tipo "Correttore ortografico e
> > dizionario dei sinonimi per la lingua Italiana/Francese/..." e 600 sono
> > legate al fatto che il risolutore non-lineare di Sun/Oracle sembra
> > essere stato spostato nel ramo principale dei sorgenti.
> >
> > Si tratta di un volume gestibile senza particolari difficolta'.
>
> Scusate la mia latitanza, problemini di salute (soprattutto) e lavoro...
>
> Oltre a ciò che ha scritto Andrea, sto procedendo a scremare le stringhe
> da tradurre, nel senso che sto traducendo le più ovvie e quelle per le
> quali ho già la corrispondenza nella memoria di traduzione.
>
> Chi vuole iniziare a prepararsi al lavoro deve prima di tutto preparare
> gli strumenti di traduzione. Chi usa Linux può installare PoEdit o
> Lokalize, chi usa Windows può usare PoEdit.
>
> Sconsiglio l'uso di OmegaT, non perché sia un cattivo strumento di
> traduzione, ma perché gestisce male la polisemicità dei vocaboli
> inglesi, in particolar modo nelle stringhe con un solo vocabolo, tipiche
> delle interfacce. Sebbene sia stata introdotta una nuova funzionalità,
> il programma rischia di creare errori.
>
> I CAT tool specificamente dedicati ai file .po non presentano questo
> problema e da questo punto di vista siamo tranquilli.
>
> Entro questa settimana dovrei riuscire ad avere i file pronti, sempre
> che non ci siano, come ha fatto puntualmente notare Andrea, correzioni
> dell'ultim'ora.
>
> Ciao!
> --
> Valter
> *Open Source is better!*
> KDE: www.kde.org
> Kubuntu: www.kubuntu.org
> LibreOffice: www.libreoffice.org
>

> Il 01/01/2012 18:49, Andrea Pescetti ha scritto:
>
>> Il 21/12/2011 Valter Mura ha scritto:
>>> fra qualche giorno vi aggiornerò sul da farsi.
>>
>> Se qualcun altro e' in attesa di notizie, io ho fatto un po' di prove
>> con gli strumenti e le procedure che suggeriva Valter e funziona tutto.
>>
>> Le stringhe sono semidefinitive ma non ancora definitive al 100%, vedete
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb 
>>
>>
>> (se ne capite appena di codice, vedrete che ridefinisce le stringhe
>> inglesi "Insert Rows" e "Insert Columns" in modo che siano indipendenti
>> perche' necessario per tradurle in alcune lingue; e' di oggi).
>>
>> Il volume di traduzioni e' stimabile in circa 4000 parole sia per la
>> guida sia per l'interfaccia utente; queste ultime sembrano molte, ma ad
>> esempio 600 sono in stringhe del tipo "Correttore ortografico e
>> dizionario dei sinonimi per la lingua Italiana/Francese/..." e 600 sono
>> legate al fatto che il risolutore non-lineare di Sun/Oracle sembra
>> essere stato spostato nel ramo principale dei sorgenti.
>>
>> Si tratta di un volume gestibile senza particolari difficolta'.
>
> Scusate la mia latitanza, problemini di salute (soprattutto) e lavoro...
>
> Oltre a ciò che ha scritto Andrea, sto procedendo a scremare le
> stringhe da tradurre, nel senso che sto traducendo le più ovvie e
> quelle per le quali ho già la corrispondenza nella memoria di traduzione.
>
> Chi vuole iniziare a prepararsi al lavoro deve prima di tutto
> preparare gli strumenti di traduzione. Chi usa Linux può installare
> PoEdit o Lokalize, chi usa Windows può usare PoEdit.
>
> Sconsiglio l'uso di OmegaT, non perché sia un cattivo strumento di
> traduzione, ma perché gestisce male la polisemicità dei vocaboli
> inglesi, in particolar modo nelle stringhe con un solo vocabolo,
> tipiche delle interfacce. Sebbene sia stata introdotta una nuova
> funzionalità, il programma rischia di creare errori.
>
> I CAT tool specificamente dedicati ai file .po non presentano questo
> problema e da questo punto di vista siamo tranquilli.
>
> Entro questa settimana dovrei riuscire ad avere i file pronti, sempre
> che non ci siano, come ha fatto puntualmente notare Andrea, correzioni
> dell'ultim'ora.
>
> Ciao!