Re: cdimage pages in wml
On Thu, 1 Mar 2001, Josip Rodin wrote:
> On Thu, Mar 01, 2001 at 02:47:42PM +0100, J.A. Bezemer wrote:
> > One problem: cdimage.d.o does not do content negotiation, and even if it did
> > I'd refuse to use it[*]. So a reference to just "faq" won't work, it has to be
> > "faq.en.html". Is there any wml trick that can automagically add the
> > ".<lang>.html" or do I have to hard-code it everywhere?
> > [*]: It does not work, period. Many browsers have incorrect settings
> > _per_default_, up to the point that I believe we're losing many Windows
> > converts because they simply can't read our webpages. I don't want to be
> > responsible for anything like that.
> There's nothing inherently wrong with content negotiation, and the current
> implementation works just fine in a majority of cases. In cases where it
> doesn't work, it mostly a user-error, and it can be worked around very
IMnsHO a "majority of cases" is a wrong attitude. It should work in _all_
cases, for all browsers with all settings. If we'd make a flash-only site,
we'd still be supporting a majority of viewers, and the unsupported minority
would need to make some adjustments to view the site properly. Why don't we do
By the way, I don't think you have any numbers on that "majority" since I'm
not aware of any way that apache can produce them. I mean something like:
IP address, hostname, URL requested, languages requested, actual page served.
I'd surely like to see and analyse factual data like that.
Furthermore I disagree that it's mostly a user error. Most users don't even
know that there is such a thing as language preferences. They use settings
their browser is shipped with (and/or are autodetected?). I've seen quite a
few of these cases in debian-doc (I guess debian-www gets even more), for
In IE 5.5 the _default_ language is "English (United States) [en-us]". Once
I changed that to "English [en]" everything worked fine.
I do appreciate learning something _new_.
Finally, the workaround (i.e. other than fixing the language preferences) of
adding .en.html or /index.en.html is definately not easy in two aspects:
1) people don't know this workaround _exists_, and 2) you've got to add it
_every_ _time_ you click on a link. The first is solved partly by the
language list at the bottom of some pages, the second _can_ be solved partly
by providing specific hrefs.
> www.debian.org and all of its mirrors have been running Apache(s) with
> content negotiation for years now. We get complaints from users who set up
> their browsers incorrectly, all the time, and it obviously hasn't stopped
> us, and I doubt it will.
If you get complaints, you're doing something wrong. You're running a
web-servant, not a web-dictator.
> > > BTW, would you mind if I renamed ch* files to something nicer? It's not
> > > really important, but it's easier to handle files that aren't so similarly
> > > named.
> > Well, if you have any good suggestion that increases manageability please
> > tell me. And remember that I'm mostly using mc(1) to work on stuff, so the
> > names should preferably have less than 16 and absolutely less than 37
> > characters (which makes it quite hard to think of good descriptive names
> > for ch21211 for example).
> For example, "p-ikit" (short for pseudo-image kit). Or something along those
> lines. Anything's better than combinations of numbers 1, 2 and 3...
This won't help; there are four different pages directing to the Kit, how to
distinguish them? And there are twelve different non-terminal pages, how to
call them? I didn't know and still don't know, that's why I named them
according to the _ch_oices made.