Subject: Re: [htdig] Distributions (was Red Hat 7.0 RPMS?)
From: Gilles Detillieux (firstname.lastname@example.org)
Date: Wed Oct 11 2000 - 10:13:31 PDT
According to Geoff Hutchison:
> At 11:20 AM +0200 10/11/00, Charles Nepote wrote:
> >PS : I am still thinking that htdig group may provide a 3.1.6 version
> >with accent patch and international stuff as :
Hey, if you want to put in several full days comitting to CVS, one by
one, all the changes you think should go in (after putting each one to a
vote on the htdig3-dev list, of course), and properly documenting each
and every one of these changes, you're welcome to do so. Maybe then
you'll have a bit more of an appreciation of how much work it is to put
together a release. Bear in mind that only one or two of the dozen or
so patches in the archives for 3.1.5 have any documentation at all,
and many of these patches aren't quite ready for prime-time either.
Feel up to the challenge?
I've coordinated the releases of 3.1.3 - 3.1.5, and can say it's a huge
amount of work. And I still relied on Geoff to tie up some loose ends
that I'd inevitably forget. Neither Geoff nor I has the time to spare
on this. We barely have time to get the next beta of 3.2 off the ground.
> >-- ad minima : change the /opt/www/htdig/common to
> >/opt/www/htdig/english : that will let users decide to create
> >/opt/www/htdig/french if they want it ;
There's nothing in the current default name for the common directory
that prevents you from creating any other name you want for other
languages. FAQ 4.10 suggests creating directories for other languages
as subdirectories of the common directory, but of course that's up to
the installer. Having ready-made language-specific directory names
would make a lot more sense if the package actually did include files
for several languages (see note below). However, if you change a default
like this, you'll also need to check over all the documentation to make
sure it agrees with this change (including the FAQ), plus you'll have to
be ready to deal with the fallout from users who got used to the default
being one particular way, and don't like the change (especially since
the distribution only includes English files anyway).
> >-- ad minima : change /opt/www/htdocs/htdig/search.html to
> >/opt/www/htdocs/htdig/english/search.html ;
Is "search" not already an English word? You could also put a suche.html
and a recherche.html in the same directory, or use language codes in
the file names. Most users would likely prefer the default file to go
into their document root, but of course with so many different setups,
you can't please everyone. One thing is pretty certain, though: a lot
of users don't like having a whole lot of extra levels of directories
when they don't want it. It's all pretty academic as far as this one
file is concerned, though, as this is easily changed with one option
to the ./configure script. Your preferred default isn't necessarily
> >-- options : suppress hard coded english pages to use .html (and join
> >search.html in the same directory as headers and footers and so on) ;
OK, this is really two separate and loosely related changes:
1) putting search.html with the headers and footers.
This implies that the search.html file should be treated as a
template, and not a static HTML file. This has been suggested
already, and would mean changing htsearch to produce a blank search
form from the template under some circumstances (e.g. the "words"
input parameter is empty). Putting a static HTML file in the same
directory as the templates doesn't make sense, as the templates are
normally installed outside of your server's document root hierarchy
(unless you've misconfigured your ht://Dig package, and we're not
about to standardize misconfigurations).
2) getting rid of hard-coded English in htsearch.
This is probably the most important of all your suggestions, and it
should be given priority over the others. There are a couple snags
that have made it difficult to do this so far. As you know, almost all
English-specific strings can be changed via configuration attributes,
or by changing the template files. The exceptions to this are some
built-in error message pages for missing config file or missing
database files, and the syntax error messages for boolean searches.
The difficulty in internationalizing the syntax error messages is that
different languages may require a different syntax, i.e. a different
order for the words in the message, so it may not be a simple matter
of adding config attributes for each English phrase that the parser
uses to build up the message string. However, that would at least
be a start.
The difficulty in internationalizing the message for a missing config
file is that all the strings you configure in for other languages
normally go in that config file. If htsearch can't find it, how does
it know how to tell you that in your own language?
We're open to suggestions and/or contributions in this area.
> >-- options : add french and german versions of html file, which are
> >ready (like other languages I guess).
This is something we'd really like to be able to do, and have asked for
contributions many times. With the exception of Didier Lebrun's "kit
de francisation", which we point to in our FAQ, we've received almost
nothing (a couple German word lists and an affix file are the exception).
If we can get enough complete contributions for at least 2 to 4 languages,
it would be worth our while to integrate them in the package (provided
we can get help in updating them as the package evolves). As long as
the contributions are incomplete and piecemeal as they are now, all we
can do is point users to the individual bits and pieces and wish them
luck in getting the rest set up.
If any of you are thinking of contributing something, please take a look
at Didier's kit. With the exception of a synonyms file, his kit is very
complete. We'd love to have similar kits for German, Spanish and Italian,
and anything else that users see fit to contribute.
> >-- options : conform to the Linux Standard Base.
> >(I know I can to all this things by hand...)
> >I know the htdig group is working on such subjects for next release (I
> >saw the works of Sanga), but may 3.1.5 should already have those changes
> >with a little work to do ?...
> Because rolling a release takes quite a bit more time than you'd
> expect. (It always seems to take quite a bit more time than I
> expect!) Since you can set all of these installation paths quite
> easily, this does not make it a high priority. If, for some reason, a
> significant security hole is discovered or other significant bug,
> then a 3.1.6 release will be made to fix that.
I'm with Geoff on this point. A security hole or a major bug
would warrant a new 3.1.x release as long as 3.2.x isn't yet stable.
Anything else is taking away from where we should be spending our time.
Even if I did have 3 or 4 days to kill (which I MOST certainly do NOT),
that time would be much better spent on tackling 3.2's to-do list rather
than keeping a dying branch alive.
There are a lot of problems and shortcomings in 3.1.5 that are fixed,
or will be fixed, in 3.2, and can't readily be backported to 3.1.x.
If you really want to help things move in the right direction, please
help out with the 3.2.0 development and testing instead of repeatedly
begging for more 3.1.x releases. What you think is "a little work to do"
is really a big job you're expecting someone else to do for you.
-- Gilles R. Detillieux E-mail: <email@example.com> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------ To unsubscribe from the htdig mailing list, send a message to firstname.lastname@example.org You will receive a message to confirm this. List archives: <http://www.htdig.org/mail/menu.html> FAQ: <http://www.htdig.org/FAQ.html>
This archive was generated by hypermail 2b28 : Wed Oct 11 2000 - 10:18:38 PDT