| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes: 832039
|
|
|
|
Closes: 825216
|
|
Quite a huge churn of new strings.
|
|
|
|
Closes: 827067
|
|
|
|
Closes: 826291
|
|
Closes: 824702
|
|
|
|
|
|
Closes: 823976
|
|
Users have the option since apt >= 1.1 to enforce that a Release file is
signed with specific key(s) either via keyring filename or fingerprints.
This commit adds an entry with the same name and value (except that it
doesn't accept filenames for obvious reasons) to the Release file so
that the repository owner can set a default value for this setting
effecting the *next* Release file, not the current one, which provides a
functionality similar "HTTP Public Key Pinning". The pinning is in
effect as long as the (then old) Release file is considered valid, but
it is also ignored if the Release file has no Valid-Until at all.
|
|
|
|
This is a duplicate of sorts of 0efb29eb36184bbe6de7b1013d1898796d94b171
which is the a lot more frequent case of this error – and also a
duplicate of this error message, just without the \n at the end.
Git-Dch: Ignore
|
|
|
|
Closes: 820638
|
|
|
|
Closes: 819938
|
|
|
|
|
|
|
|
100% translated.
Note: this commit contains a message from the future. #818639
|
|
Note, 0 untran, 1 fuzzy, and the fuzzy string remains at Bug#818639.
|
|
|
|
|
|
"%s can not be marked as it is not installed." was incorrectly
translated as "%s no se puede marcar como no instalado.\n",
which means "%s can not be marked as not installed."
Thanks to Marcos Del Sol Vives for reporting & to the spanish
translation team – and in particular Camaleón and Venturi –
for review and correction of this issue!
[commit message by commiter]
Closes: 817999
|
|
Closes: 817060
|
|
Build system messed up the 1.2.2 commit by not updating the
.po files properly, so they are now.
|
|
|
|
Closes: 813467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Korean translation update is attached.
I downloaded the original from https://www.debian.org/international/l10n/po/ko.
Originally, "manually" and "automatically" were translated same,
which was confusing.
Mail-Reference: <CAPrzcnL_YynHQkCSE4xH29eW1O0Q6SPhoSf21KOFTu=Vv6-0Nw@mail.gmail.com>
Mail-Archive: https://lists.debian.org/deity/2015/12/msg00108.html
|
|
|
|
Git-dch: ignore
|
|
|
|
|
|
Reference mail:
https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
|
|
Git-Dch: Ignore
|
|
The general idea is: A small paragraph on the tool itself as a
description, a list of the most used (!= all) commands available in the
tool, a remark where to find more information on the tool and its
commands (aka: in the manpage) and finally a common block referring to
even more manpages. In exchange options are completely omitted from the
output as well as deprecated or obscure commands. (Better) Information
about them is available in the manpages anyway and the few options which
were listed before were also the least interesting ones (-o -c -q and co
are hardly of interest for someone totally new looking to find info by
asking for help and anyone with a bit of experience doesn't need this
short list. Those would need a list of options applying to the command
they call, but they are too numerous and command specific to list them
sanely in this context.
|
|
That is one huge commit with busy work only: Help messages used to be
one big translateable string, which is a pain for translators and hard
to reuse for us. This change there 'explodes' this single string into
new string for each documented string trying hard to split up the
translated messages as well. This actually restores many translations as
previously adding a single command made all of the bug message fuzzy.
The splitup also highlighted that its easy to forget a line, duplicate
one and similar stuff.
Git-Dch: Ignore
|
