Re: Q: Can you please assist me with translation?

[Paul Eggert]

> Date: Mon, 15 Apr 2002 11:56:07 +0200 (CEST)
> From: Mirsad Todorovac <address@hidden>

> 1.
> 
> # FIXME -- find `padež' here from source
> #: src/create.c:151
> msgid "Generating negative octal headers"
> msgstr "Generiram negativna oktalna zaglavlja"
> 
>       Here I haven't realized in which person and declination
>       is this "Generating negative octal headers" said;
>       is it "Now I am generating octal headers" or
>       "While generating octal headers" or something else?

More the former.  It is a warning that "tar" is generating negative
octal headers, which is usually undesirable.

> 2.
> 
> # FIXME -- non-header dubious -- clean against source! -- TM
> #: src/delete.c:258
> msgid "Deleting non-header from archive"
> msgstr "Brišem non-header iz arhive"
> 
>       "Deleting non-header from archive" -- what is program really
>       doing here?

"tar" read something from the archive that was not a valid tar header.
Since it doesn't know what to do with the data, it deletes it.

> 3.
> 
> # FIXME -- clarify this against source -- TM -- didn't help
> #: src/extract.c:1216
> msgid "Visible long name error"
> msgstr "Vidljiva pogreška s dugim imenom"
> 
>       What does this mean exactly?

"tar" read a LONGNAME or LONGLINK header from the archive in a context
where it was not expected.

> 4.
> 
>  FIXME -- obsolescent -- TM
> #: src/list.c:632
> msgid "Archive contains obsolescent base-64 headers"
> msgstr "Arhiva sadrži zastarjela base-64 zaglavlja"
> 
>       What are exactly these base-64 and base-256 headers?

The tar format uses null-terminated octal ASCII to represent numbers.
For file sizes, for example, the standard tar header format reserves
12 bytes, which means that files with at least 8**(12-1) bytes == 8
GiB cannot be represented.  This causes problems in practice, so when
a file is larger than that, GNU tar uses an extension: it stores the
size using a base 256 representation, which means it can represent
files up to 256**12 bytes == 65536 YiB.  This should be enough for
quite some time.


> 5.
> 
> # FIXME??
> #: src/list.c:645
> #, c-format
> msgid "Archive signed base-64 string %s is out of %s range"
> msgstr "Base-64 potpis %s arhive je izvan %s opsega"
> 
>       Can you please explain further this?
>       Is this a sort of signature of the content or what?

The archive contains a base-64 number (like a file size) that is too
large to be represented on this host.  If it is a file size, the type
will be "off_t"; that word need not be translated since it is a
C-language type.


> 6.
> 
> # FIXME -- clarify against source -- TM
> #: src/list.c:1108
> #, c-format
> msgid "--Continued at byte %s--\n"
> msgstr "--Nastavljeno sa bajtom %s--\n"
> 
>       What is continued here? I suppose archive, but if I'm
>       not sure about the original, then I can be even less
>       sure about the translation, wouldn't you agree.

It's a header that was so long that it didn't fit into the previous
volume, so it's split across volumes, at the indicated byte offset.


> 7.
> 
> # FIXME -- 'mangled filenames'???
> #: src/list.c:1112
> msgid "--Mangled file names--\n"
> msgstr "--Manglirana imena datoteka--\n"
> 
>       Can you explain further mangled filenames, their
>       use in GNU tar (which is off course rather sophisticated
>       software)?

Sorry, haven't a clue.  Mangled file names are no longer supported,
so I wouldn't worry too much about it.


> 8.
> 
> # FIXME -- now this is supposed to be funny
> #: src/rmt.c:560
> #, c-format
> msgid "rmtd: Garbage command %c\n"
> msgstr "rmtd: %c je smeće of naredbe\n"
> 
>       What types of commands are considered 'garbage'
>       and when this occurs?

Any command that "rmt" can't parse.  This occurs if the rmt client
sends it a command that rmt doesn't understand.

> 9. Can you please explain the use of 'volume number'
>    term?

GNU tar can create archives on multiple volumes, typically multiple
tapes if the archive is too large to fit on a tape.

> 10. "  -i, --ignore-zeros             ignore zeroed blocks in archive
> (means EOF)\n"
> 
>       I've read about this in manual, but this still looks rather
> cryptic

It means the default is that two blocks of zero mean EOF, as the POSIX
standard requires this.  But if you have a bad tar image you may want
to ignore the zero-blocks and keep reading; if so, you use this option.