| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
The bugreport is more conservative in asking for a conditional, but
given that this is a message intended to be read by users to be run by
users we should suggest using a command intended to be used by users.
And while we are at, add sudo to the message – conditional of course.
Closes: 801571
|
|
Git-dch: ignore
|
|
A bit unfair that only Bzr had this message. Lets at least print it for
git as well with the option of adding more later without string changes.
|
|
|
|
|
|
|
|
apt-get is displaying various lists of package names, which until now it
was building as a string before passing it to ShowList, which inserted
linebreaks at fitting points and showed a title if needed, but it never
really understood what it was working with. With the help of C++11 the
new generic knows not only what it works with, but generates the list on
the fly rather than asking for it and potentially discarding parts of
the input (= the non-default verbose display). It also doubles as a test
for how usable the CacheSets are with C++11.
(Not all callers are adapted yet.)
Git-Dch: Ignore
|
|
Again, consistency is the main sellingpoint here, but this way it is now
also easier to explain that some files move through different stages and
lines are printed for them hence multiple times: That is a bit hard to
believe if the number is changing all the time, but now that it keeps
consistent.
|
|
Implementing FileName() works for most cases for us, but other
frontends might need more and even for us its not very stable as
the normal Jump() implementation is pretty bad on a deb file and
produce errors on its own at times.
So, replacing this makeshift with a complete implementation by
mostly just shuffling code around.
|
|
|
|
|
|
|
|
|
|
Git-dch: ignore
|
|
Git-Dch: Ignore
|
|
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fixes some messages and their translation so that all of them have three
dots for messages with an elipse. Many translations already had this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nl_langinfo is used to acquire the YESEXPR of the language used,
but it will return the one from LC_MESSAGES, which might be different
from the language chosen for display of the question (based on LANGUAGE)
so this commit removes the [Y/n] help text from the questions itself and
moves it to the prompt creation in which the usage of LC_MESSAGES is
forced for it, so that the helptext shown actually represents the
characters accepted as input for the question.
There is still room for problems of course starting with an untranslated
"[Y/n]" but a translated YESEXPR or the problem that the question is
asked in a completely different language which might have a conflicting
definition of [Y/n] input or the user simple ignores the helptext and
assumes that an answer matching the question language is accepted, but
the mayority of users will never have this problem to begin with, so we
should be fine (or at least a bit finer than before).
Closes nothing really, but should at least help a bit with bugs like
deb:194614, deb:471102, lp:1205578, and countless others.
|
|
|
|
|
|
translations. Closes: #705087
|
