[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#669880: marked as done (apt: lack of translations should not be an error)



Your message dated Wed, 16 May 2012 15:29:14 +0200
with message-id <CAAZ6_fDENXwtoDEtrspT22WjCYwXQ0nVv+28gcDwcr1Rcy0RLg@mail.gmail.com>
and subject line Re: Bug#669880: apt-get should work better with partial mirrors
has caused the Debian Bug report #669880,
regarding apt: lack of translations should not be an error
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
669880: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669880
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 0.9.2
Severity: serious

This is on a qemu virtual machine whose sources.list points to a
partial mirror not having any other translation file other than
"Translation-en":

qemu:~# apt-get update
Des:1 http://mypartialmirror sid InRelease [210 kB]
Des:2 http://mypartialmirror sid/main amd64 Packages [5950 kB]
Des:3 http://mypartialmirror sid/contrib amd64 Packages [45,5 kB]
Des:4 http://mypartialmirror sid/non-free amd64 Packages [81,8 kB]
Des:5 http://mypartialmirror sid/contrib Translation-en [37,0 kB]
Des:6 http://mypartialmirror sid/main Translation-en [3940 kB]
Des:7 http://mypartialmirror sid/non-free Translation-en [69,2 kB]
Err http://mypartialmirror sid/main Translation-es          
  
Err http://mypartialmirror sid/main Translation-es
  
Err http://mypartialmirror sid/main Translation-es
  
Err http://mypartialmirror sid/main Translation-es
  404  Not Found
Descargados 10,3 MB en 4seg. (2394 kB/s)
W: Imposible obtener http://mypartialmirror/debian/dists/sid/main/i18n/Translation-es  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.


IMHO, this should never happen. If Translation-en is available, then a
missing Translation-es (or any other translation file) should never
be a fatal error.

Thanks.



--- End Message ---
--- Begin Message ---
On Wed, May 16, 2012 at 1:50 PM, Santiago Vila <sanvila@unex.es> wrote:
> After upgrading to apt 0.9.3, I have seen apt-get to fail when
> Translation-es was not available.

As Translations are important for many people to understand what
is going on/what they do as not everyone speaks english at all or fluently
i don't see the problem in at least notifying the user that he will not have
updated Translations and therefore in extreme cases will not know what
a package does (and is therefore okay to be installed/removed or not). [0]

This is not a fatal failure, APT will proceed to work with whatever it has
got, it will just not be able to show new/updated translations because
it couldn't download them and more and more package descriptions will
be displayed in english because the translation isn't current anymore.
Just what the error message tries to tell you.


> The funny thing is that even by setting LANG=C, apt-get *still* tried
> to retrieve Translation-es. This does not make much sense.

That is not funny nor does it make no sense.
Scripts (like a cronjob) as well as many frontends run apt-get and
it's library providing the functionality in LANG=C (or just in a different
environment than a "normal" user would do), still it would be
misfortune to download no translation (or only -en in that case).

APT therefore looks into /var/lib/apt/lists directory for downloaded
Translation files with the assumption that if you have it downloaded
the last time you will properly want it this time, too.

If you don't want any translation the manpage is your friend.
It says: "To force apt to use no Translation file use the
 setting Acquire::Languages=none".


It is also needed for situations in which e.g. two different admins
work on the same system which have different language settings -
one would constantly override the language settings of the other.

(And from a technical point, it allows us to keep our binary cache
 valid as this would need to be build for each user/script/… differently
 wasting quiet a bit of time making e.g. auto-completion useless)

So yes, this is a try at doing the right thing by default.
That this is not the right thing for you is misfortune,
but unavoidable as we can't make everyone happy by default.

I know that APT in squeeze ignored it if it couldn't acquire translations,
but this was mostly caused by the inability to know if they would be
available at all and if it could decompress them. The first is fixed now
as the Release file includes them, so we know what we can expect,
the second is no longer true as we link against libbz2, so we can be
sure that we have the necessary means to decompress them.
So if the settings dictate that we should download the file if available
and as we know that it will be available we get it and if we can't we
complain about it.


We have an incredible amount of settings to tweak the behavior
in many different ways so feel free to tweak them to suit your needs
and in the event we don't have an option for it feel free to request it
(one more option will properly not kill us, even through many people
 say otherwise in terms of being able to test all options in all combinations,
 but that train has left the station long time ago anyway…).

(if it's not clear until now: Closing because of that as no-bug)

Best regards

David Kalnischkies

[0] We can argue now how useful DDTP is and how much Translations
would need to be available to consider it useful, but in the end translated
long-descriptions is a feature other distributions are jealous of us for a
reason and I like them and want to push the work some people do to people
who might be happy that they do it - and usually stuff will be improved
further by using it by default, not by hiding it in the basement by default.

P.S.: To the best of my knowledge, the language code for klingon is "tlh"
and a few packages (namely anki and tuxpaint) provide it…


--- End Message ---

Reply to: