Traduzione di gettext-tools (parte 3)
Danilo Piazzalunga
danilopiazza@libero.it
Ven 8 Apr 2005 03:00:44 CEST
On Wednesday 30 March 2005 17:54, Marco Colombo wrote:
> # FIXME: clauses???
> #: src/format-lisp.c:2906
> #, c-format, fuzzy
> msgid ""
> "In the directive number %u, '~:[' is not followed by two clauses,
> separated " "by '~;'."
> msgstr "Nella direttiva numero %u, \"~:[\" non è seguito da due ...,
> separate da \"~;\"."
Letteralmente è proposizione. Dopo un'occhiata a [1] e [2], direi che è un
termine abbastanza generico per cui possiamo usare "istruzione" (o
"espressione"). Servirebbe una conferma da qualcuno che conosca un minimo di
Lisp.
[1] http://www.lisp.org/HyperSpec/Body/sec_22-3-7-2.html
[2] http://www.lisp.org/HyperSpec/Body/sec_22-3-9-1.html
> # FIXME
> #: src/po-charset.c:292 src/po-charset.c:322
> msgid "Continuing anyway, expect parse errors."
> msgstr "Si continua comunque, errori di comprensione previsti."
Si continua comunque, ma si prevedono errori di comprensione/analisi/parsing ?
> # FIXME
> #: src/po-charset.c:352
> #, c-format
> msgid ""
> "Charset missing in header.\n"
> "Message conversion to user's charset will not work.\n"
> msgstr ""
> "Charset mancante nell'intestazione.\n"
> "La conversione del messagio nel charset dell'utente non funzionerà.\n"
"L'intestazione non specifica un set di caratteri.\n"
"La conversione del messaggio nel set di caratteri dell'utente non funzionerà.
\n"
Come mai non usi "set di caratteri" in questo messaggio?
> #: src/po-gram-gen.y:94
> #, c-format
> msgid "inconsistent use of #~"
> msgstr "uso inconsistente di #~"
Uhm... "uso scorretto"? "uso improprio"? Mi sembra si adattino meglio per
descrivere un errore nella grammatica.
> #: src/po-gram-gen.y:198
> #, c-format
> msgid "missing `msgstr[]' section"
> msgstr "sezione \"msgstr[]\" mancante"
>
> #: src/po-gram-gen.y:206
> #, c-format
> msgid "missing `msgid_plural' section"
> msgstr "sezione \"msgid_plural\" mancante"
>
> #: src/po-gram-gen.y:213
> #, c-format
> msgid "missing `msgstr' section"
> msgstr "sezione \"msgstr\" mancante"
Preferirei "manca la sezione [...]"
> #: src/po-gram-gen.y:258
> #, c-format
> msgid "first plural form has nonzero index"
> msgstr "la prima forma plurale ha indice non zero"
"... diverso da zero" ?
> # FIXME
> #: src/read-mo.c:171
> #, c-format
> msgid "file \"%s\" contains a not NUL terminated string, at %s"
> msgstr "il file \"%s\" contiene una stringa non terminata da NUL, a %s"
^^^^^
È qui che hai il dubbio, vero?
La stringa viene sostituita da "sysdep_segment[ <numero> ]".
Credo che "... stringa non terminata da NUL, in %s" possa andare bene.
Dal sorgente:
char location[30];
sprintf (location, "sysdep_segment[%u]", (unsigned int) sysdepref);
error (EXIT_FAILURE, 0,
_("file \"%s\" contains a not NUL terminated string, at %s"),
bfp->filename, location);
> #: src/read-properties.c:215
> #, c-format
> msgid "%s:%lu: warning: invalid \\uxxxx syntax for Unicode character"
> msgstr "%s:%lu: attenzione: sintassy \\uxxxx non valida "
^^^^^
Syntassy ?!? ;-)
> "for un carattere Unicode"
^^^
For ?!? ;-)
> #: src/write-csharp.c:675 src/write-java.c:992
> #, c-format
> msgid "cannot create a temporary directory using template \"%s\""
> msgstr "impossibile creare la directory temporanea usando il template
> \"%s\""
s/template/modello/ ?
Credo che si riferisca al modello "/tmp/directory.XXXXXX" da usare con
mktemp() e simili, vedi anche mktemp(1).
> #: src/write-po.c:852 src/write-po.c:918
> #, c-format
> msgid ""
> "The following msgid contains non-ASCII characters.\n"
> "This will cause problems to translators who use a character encoding\n"
> "different from yours. Consider using a pure ASCII msgid instead.\n"
> "%s\n"
> msgstr ""
> "Il seguente msgid contiene caratteri non ASCII.\n"
> "Questo può causare problemi ai traduttori che usano una codifica\n"
> "diversa da questa. "
Che ne pensi di "diversa dalla propria" ?
> #: src/write-po.c:1063
> #, c-format
> msgid ""
> "Cannot output multiple translation domains into a single file with Java ."
> "properties syntax. Try using PO file syntax instead."
> msgstr ""
Questo non è tradotto. Vediamo un po'...
"Impossibile scrivere più domini di traduzione in un singolo file con la
sintassi Java properties. Provare a usare la sintassi dei file PO."
> #: src/write-po.c:1065
> #, c-format
> msgid ""
> "Cannot output multiple translation domains into a single file with
> NeXTstep/" "GNUstep .strings syntax."
> msgstr ""
Anche questo non è tradotto.
"Impossibile scrivere più domini di traduzione in un singolo file con la
sintassi NeXTstep/GNUstep .strings."
> #: src/write-qt.c:499
> #, fuzzy
> msgid ""
> "message catalog has msgid strings containing characters outside
> ISO-8859-1\n" "but the Qt message catalog format supports Unicode only in
> the translated\n" "strings, not in the untranslated strings\n"
> msgstr ""
> "Il catalogo dei messaggi contiene strighe msgid con caratteri non in
> ISO-8859-1,\n"
> "ma il formato dei cataloghi Qt gestisce Unicode solo nelle stringhe
> tradotte,\n" "non in quelle originali\n"
Per me va bene così.
> # FIXME
> #: src/write-resources.c:96
> #, c-format
> msgid "error while writing to %s subprocess"
> msgstr "errore durante la scrittura sul sottoprocesso %s"
Va bene, anche gli altri messaggi simili nella parte 2 li abbiamo lasciati
così.
> #: src/x-c.c:1093 src/x-csharp.c:1498 src/x-java.c:826
> #, c-format
> msgid "%s:%d: warning: unterminated character constant"
> msgstr "%s:%d: attenzione: costante carattere non terminata"
>
> # FIXME
> #: src/x-c.c:1117
> #, c-format
> msgid "%s:%d: warning: unterminated string literal"
> msgstr "%s:%d: attenzione: letterale stringa non terminato"
Considerando che "char. constant" (sopra) ha lo stesso significato di "char.
literal" e che la traduzione sopra va bene, direi di mettere:
"... costante stringa non terminata"
> #: src/x-csharp.c:1501 src/x-java.c:829
> #, c-format
> msgid "%s:%d: warning: unterminated string constant"
> msgstr "%s:%d: attenzione: costante stringa non terminata"
Sì, decisamente "string constant" e "string literal" sono sinonimi, solo che
il secondo sembra più usato nella comunità C.
(Sono solo commenti miei, non c'entrano un tubo con la revisione)
> # FIXME
> #: src/x-perl.c:1038
> #, c-format
> msgid "%s:%d: missing right brace on \\x{HEXNUMBER}"
> msgstr "%s:%d: \"}\" mancante in \\x{HEXNUMBER}"
A occhio (non ho trovato documentazione per questa sintassi), direi che va
bene. Forse HEXNUMBER è traducibile, ma dato che questo messaggio è rivolto
al programmatore è meglio non sottilizzare troppo.
> #: src/xgettext.c:748
> #, c-format
> msgid ""
> " -d, --default-domain=NAME use NAME.po for output (instead of
> messages." "po)\n"
> msgstr " -d, --default-domain=NOME usa NAME.po per l'output (invece di
^^^^
Metti NOME anche qui.
> messages.po)\n"
> # FIXME
> #: src/xgettext.c:757
> #, c-format
> msgid "Choice of input file language:\n"
> msgstr "Scelta del linguaggio del file di input:\n"
Va bene, è esattamente quello di cui si occupa l'opzione sottostante.
> #: src/xgettext.c:767
> #, c-format
> msgid ""
> "By default the language is guessed depending on the input file name "
> "extension.\n"
> msgstr "Come impostazione predefinita, la scelta della lingua si basa
> sull'estensione del file di input.\n"
s/lingua/linguaggio/
Qui si riferisce al linguaggio di programmazione in cui è scritto il file di
input, che è sempre un file sorgente.
> #: src/xgettext.c:775
> #, c-format, fuzzy
> msgid "By default the input files are assumed to be in ASCII.\n"
> msgstr "Come impostazione predefinita, i file di input si assumono essere
> ASCII.\n"
"... i file di input si considerano ASCII" ?
Eviterei la forma accusativo+infinito così tipicamente anglofona :-)
> #: src/xgettext.c:780
> #, c-format
> msgid " -j, --join-existing join messages with existing file\n"
> msgstr " -j, --join-existing unisci i messaggi con il file
^^^^^^
unisce
> esistente\n"
> #: src/xgettext.c:784
> #, c-format
> msgid ""
> " -c, --add-comments[=TAG] place comment block with TAG (or those\n"
> " preceding keyword lines) in output file\n"
> msgstr ""
Proviamo con questa:
" -c, --add-comments[=TAG] mette il blocco di commenti che contiene TAG\n"
" (o le righe di parole chiave che le
precedono)\n"
" nel file di output"
Forse è meglio chiedere una spiegazione all'autore...
> #: src/xgettext.c:788
> #, c-format, fuzzy
> msgid "Language specific options:\n"
> msgstr "Opzioni di linguaggio specifiche:\n"
"Opzioni specifiche a seconda del linguaggio" ?
> #: src/xgettext.c:796
> #, c-format
> msgid ""
> " -k, --keyword[=WORD] additional keyword to be looked for
> (without\n"
> " WORD means not to use default keywords)\n"
> msgstr ""
" -k, --keyword[=PAROLA] parola chiave aggiuntiva da cercare (senza\n"
" PAROLA indica di non usare le parole chiave\n"
" predefinite)\n"
> #: src/xgettext.c:803
> #, c-format
> msgid ""
> " --flag=WORD:ARG:FLAG additional flag for strings inside the "
> "argument\n"
> " number ARG of keyword WORD\n"
> msgstr ""
" --flag=PAROLA:ARG:FLAG flag aggiuntivo per le stringhe
nell'argomento\n"
" numero ARG della parola chiave PAROLA\n"
> #: src/xgettext.c:818
> #, c-format
> msgid ""
> " --debug more detailed formatstring recognition
> result\n"
> msgstr ""
" --debug risultato più dettagliato del riconoscimento\n"
" della stringa di formato"
Dopo una caccia tra i sorgenti, ho scoperto che stampa
"possible-<x>-format" (oltre a <x>-format, che ad es. è c-format,
perl-format, etc.) quando non riesce a determinare con certezza il formato
della stringa in questione.
> #: src/xgettext.c:852
> #, c-format
> msgid " --copyright-holder=STRING set copyright holder in output\n"
> msgstr " --copyright-holder=STRINGA imposta il titolare del copyright
> in " "output\n"
>
> #: src/xgettext.c:854
> #, c-format
> msgid ""
> " --foreign-user omit FSF copyright in output for foreign
> user\n"
> msgstr ""
Questa è la mia interpretazione: prova a inserirla (come fuzzy, così non viene
usata) in attesa di un chiarimento dall'autore.
" --foreign-user omette il copyright della FSF dall'output
per\n"
" gli utenti non GNU\n"
> #: src/xgettext.c:856
> #, c-format
> msgid ""
> " --msgid-bugs-address=EMAIL@ADDRESS set report address for msgid
> bugs\n" msgstr ""
> " --msgid-bugs-address=EMAIL@INDIRIZZO imposta l'indirizzo a cui
> segnalare\n"
> " errori negli msgid\n"
Prova a mettere "... nelle voci msgid"
> #: src/xgettext.c:1462
> #, c-format
> msgid ""
> "A --flag argument doesn't have the <keyword>:<argnum>:[pass-]<flag>
> syntax: %" "s"
> msgstr ""
Proporrei:
"Un argomento di --flag non usa la sintassi <parola_chiave>:<num_arg>:
[pass-]<flag>: %s"
L'errore viene restituito quando il parsing dell'argomento dell'opzione --flag
non va a buon fine. La stringa "pass-" compare così com'è, non è un elemento
variabile della sintassi.
> # FIXME
> #: src/xgettext.c:1733
> #, c-format, fuzzy
> msgid ""
> "Although being used in a format string position, the %s is not a valid %s
> " "format string. Reason: %s\n"
> msgstr "Sebbene usato in una posizione di formato stringa, %s non è una
> striga di formato %s valida. Motivo: %s\n"
L'unica differenza tra questo messaggio e il seguente, è che questo errore
viene restituito se quella in questione probabilmente era, in base al
contesto, una stringa di formato. La posizione si riferisce quindi al
contesto in cui la stringa compare nel sorgente (il file di input).
Proverei a proporre:
"Sebbene usata dove dovrebbe esserci una stringa di formato, %s non è una
stringa di formato %s valida. Motivo: %s\n"
> # FIXME
> #: src/xgettext.c:1733
> #, c-format, fuzzy
> msgid ""
> "Although declared as such, the %s is not a valid %s format string. Reason:
> %" "s\n"
> msgstr "Sebbene dichiarato come tale, %s non è una stringa di formato %s
^^^
dichiarata (la stringa di formato)
> valida. Motivo: %s\n"
Per il resto, questo messaggio va bene.
> # FIXME
> #: src/xgettext.c:1788
> msgid ""
> "Empty msgid. It is reserved by GNU gettext:\n"
> "gettext(\"\") returns the header entry with\n"
> "meta information, not the empty string.\n"
> msgstr ""
> "Msgid vuoto. Questo è riservato per GNU gettext:\n"
> "gettext(\"\") ritorna la voce di intestazione con\n"
> "le metainformazioni, non la stringa vuota.\n"
Cambierei solo qualcosa nella seconda riga:
"Msgid vuoto. Questo è riservato per GNU gettext:\n"
"gettext(\"\") restituisce l'intestazione, cioè la\n"
"voce con le metainformazioni, non la stringa vuota.\n"
> #: src/user-email.sh.in:340
> msgid "Which is your email address?"
> msgstr "Qual è il vostro indirizzo email?"
Ah, ecco i malefici messaggi da cui estirpare l'empio e scellerato uso della
seconda persona ;-)
Vediamo un po' se riusciamo a trovare delle alternative soddisfacenti, se no
li lasciamo come sono.
Qui lo script trova più indirizzi e chiede quale deve usare.
"Quale di questi indirizzi email si desidera usare?" oppure "è corretto?"
> #: src/user-email.sh.in:342
> msgid "Please choose the number, or enter your email address."
> msgstr "Scegliere il numero o inserire il vostro indirizzo email."
"Scegliere il numero o inserire il proprio indirizzo email."
> #: src/user-email.sh.in:362 src/user-email.sh.in:386
> src/user-email.sh.in:405
> #, fuzzy
> msgid "Invalid email address: need a fully qualified host name or domain
> name."
> msgstr "Indirizzo email non valido: nome di dominio mancante."
"... nome completo dell'host o nome di dominio mancante"
oppure
"... serve un nome completo di host o un nome di dominio"
> #: src/user-email.sh.in:372
> msgid "Is the following your email address?"
> msgstr "Il vostro indirizzo email è il seguente?"
Qui lo script trova un solo indirizzo e chiede di confermarlo.
"Il seguente indirizzo email è corretto?"
> #: src/user-email.sh.in:374
> msgid "Please confirm by pressing Return, or enter your email address."
> msgstr "Confermare premendo Invio, o inserire il vostro indirizzo email."
"Confermare premendo Invio, o inserire il proprio indirizzo email."
> #: src/user-email.sh.in:395
> msgid "Couldn't find out about your email address."
> msgstr ""
"Impossibile determinare l'indirizzo email."
> #: src/user-email.sh.in:397
> msgid "Please enter your email address."
> msgstr "Inserire il vostro indirizzo email."
"Inserire il proprio indirizzo email."
È stata davvero una splendida trilogia :-)
Ciao,
Danilo
Maggiori informazioni sulla lista
tp