html/show.tmpl: Don't allow line breaks in some link texts
If "QA Page" or "Mail Archive" get separated on two lines,
it looks just ugly. Unfuzzy the languages where no space
exists in the translation. Apply the same change for fr
since I'm reasonably certain that's the right thing to do.
Leave the more (to me) more exotic languages alone.
The uri filter in TT 2.14 (i.e. the version in Debian etch) is broken
(or at least unusable). So always use URI::Escape::uri_escape instead.
Escaping the Homepage: field makes no sense since there is no reliable
way to decide what needs to be quoted. The URIs need to be correclty
quoted in the original field already. Use HTML quoting though.
[UBUNTU] Packages::DoSearchContents: Don't die when no information is available
Issue a real error message if no contents database is available for the suite
in question.
This isn't exposed on the Debian site since we actually have _some_ contents
for every suite (experimental has contents for debian-ports.org). But on
the Ubuntu site we have no information at all for *-backports and *-updates.
(cherry picked from commit 3eda9fe5cb2a6fe0fc67493c2147d8a3ff2d904d)
Packages::Config: Add en to DDTP_LANGUAGES as well
Previously when we used DDTP_LANGUAGES and LANGUAGES together
this didn't cause any problems, but now that we evaluate them
separatly, this causes other languages to be preferred over
English, even though the user assigned a lower quality to them.
create_index_pages: Open less files simultaniously
The Ubuntu version ran out of allowed open filehandles.
Don't open the files for source and binary packages
simultaniously since that is not needed and thereby
reduce the number by 50%.
The old version was very hard on all of CPU, memory,
and I/O. The new version tries to at least lessen the
burden on memory (and to a lesser extend on CPU), in the
hopes that this will indirectly (by lesser swapping) also
reduce the stress on I/O.
In the old version we first collected all the information
about all packages and then wrote the index files one after
one with TT.
The newer version tries to write all of the index files while
collecting the package information, therefor eliminating the
need to store any information longer than needed. Because the
amount of files we can open simulaniously is limited though,
we can't write all the index files at once. Instead we write
one index files for all languages, and in a second step then
use these files to write one file per language. I tried to
use the "slice" program for that, but it also computes all
the results in memory, while I wanted to have a concurrent
approach here as well.
Since we only use a very limited subset of the features of slice
I wrote a simple replacement that supports the bare minimum of
what we need with the price that we need to be a bit careful
about the format of the slice source files.
I also don't use TT for the package entries anymore since here
as well we only used a very limited set of features and I wanted
to make this script as fast as possible (without having to rewrite
it in C ;). The header and footer still use TT since this part isn't
speed critical and we can reuse the templates we have for the dynamic
pages.
Separate handling of po translations and DDTP translations
This way we don't need to immediatly fall back to English
if people have more than one preferred language for which
only part of the page content is available.
If e.g. they would have "ca;q=0.9, de;q=0.5, en;q=0.1" in
their Accept-Language header (insert any DDTP-only language
for ca and any PO-available language for de), we can show the
description in Catalan if available, and the po contents in
German.
The code will usually try to fall back to $po_lang if a
description is not available in $ddtp_lang.
Not implemented (yet) is a DDTP language negotiation _after_
we actually know which DDTP translations are available.
The 'lang' query parameter overrides both values and has
only the fallback English (But you shouldn't use it
anyway ;).
Improve result sampling in case we have too generic keywords
Instead of either displaying the exact match if we have only
one keyword and nothing otherwise, lets try to give people
a sample of results, on the chance that might still be useful.
Mostly just display the first 100 package names found (i.e.
from suffix entries that had no "too many prefixes" value).
Allow suffix entries with "too many prefixes" value to specifiy
if the empty prefix was contained in the set (that effectivly
avoids a regression in the case "single keyword, exact match
exists").
If in doubt, prefer package names that begin with the first
keyword and only abort if we have more than 100 of those
(The worst case behaviour of this should be very limited
to due the "too many prefixes" constraints).
The text contained hardcoded English string (which was concealed
by the fact that Javascript was broken anyway and so the text
was never displayed). Now that I fixed the Javascript, fix
the l10n support, too.