Hi!
Uhm, is the huge Cc: list needed? Maybe people interested can track
the thread through <http://lists.debian.org/debian-www/> archive, I'm
not a fan of huge Cc lists. I've stripped Peter from the Cc list because
I know that he is reading the list -- after all he answered to your mail
to the list.
And, to not let it grow further, I'm reading the list, so no need to Cc
me, thanks :)
* Royandrecrabtree@aol.com [2003-08-27 23:38]:
> Keep up the good work. At least consider placing the language names
> in columns, alphabetized (or std order) by name.
Alphabetize in which order? From what I know they are sorted by their
english name. In columns? How many do you think we would need? Would
grow the page in either horizontal size or vertical size (even worse).
> Reading further down in my EMail, you would see the recommendation for a
> "brief" form in a standard location, by icon;
Reading further down in Peters EMail you would see that there is no
such thing as an icon that can represent a language. Flags only can
represent countries, and I would feel more than annoyed to have to look
for a german flag when I'm from austria.
And what about a suiss flag? Would that represent german (well, what
they call german over there ,), french or the third language they talk
over there?
Beside that Icons doesn't help people using textmode browser. We don't
want to cut the browsing ability for them.
> that would NOT take up too much space.
But would affect the usability of our page.
> Not so. And in any event, is not the case for much else on the
> web age framing (minimize/move, etc.);
> If for some reason there is a bad msisconfigure, unless you are
> using graphics, symbols set iconography will not
> be seen correctly.
Like I (and Peter) said before there is no icon representation for
languages, so it doesn't work. And it wouldn't help users of textmode
browsers.
> So the default might be to explode the language list
> alphabetically att he bottom of the page;
> perhaps the default also ought to be to put the language slection
> icon at a standard place on the
> window framing; there is a lot of room for extra icons.
We don't use frames, because their concept is flawed: You can't easily
bookmark pages that are "hidden" in frames, beside that working with
frames is a heck and when using multi frames you need to depend heavily
on JavaScript for changes to more than one frame part, which is a no
way, because the page must be usable without (there are browsers that
don't support it, and there are users that turn it off on intention).
> In a message dated 2003/08/27 08:59:21 Eastern Daylight Time,
> peter@softwolves.pp.se writes:
>> Country flags are particularly poor to use for identifying languages.
>
> Depends; if you use a qualification sequence, not so. Those who
> speak a language may not know its name,
> but may be able to recognize country of origin by flag, or read
> the cursive of that language for the name of the country.
See above. There is no country --> language link that works out well
without annoying many many people because it simply is wrong.
> Oneusage would be for a French speaker to set up for a Korean
> one; the French speaker would
> not necessarily know what the name for the Korean language would
> be in Korean; and a native
> Korean speaker would not necessarily be present (or if present,
> able to help) until time of use.
That is a awkward reasoning. People usually aren't able to read
languages without knowing what they are called. Sorry, but I can't
follow that.
> Only if you know to hold the poniter there; bas to presume without
> describing; the default form should present it explicitly;
Like Peter said, there is no much help for the representation in the
current language, so that is no big drawback.
>> IP addresses are also a poor choice for selecting languages. Currently,
>
> If no other information is present, it probably is the best choice
> available.
Switching based on IP addresses would require dynamic scripts on the
servers which we don't do. Hell, there is no _need_ for this (stupid) IP
based switching (stupid, because it doesn't work, a thing Peter tried to
explain to you), because browsers *do* send the Accept-Language header
and it is a browser setting, not a host setting.
> [a] how many people on the web world wide would get the
> correct language?
Fewer than you seem to imply.
> [c} How many viewers and per sessions who
> _use_your_website_ would get the correct language?
Many, because we tell the users about the Content Negotiation. Please
read <http://www.debian.org/intro/cn> if you haven't yet -- it seems
like you haven't, because most of your reasoning is discussed there.
Content Negotiation based on the Accept-Language header is the only
relyable and robust way to do multi language sites.
And systems set the Accept-Language nowadays to something more or less
sensible. Even Microsoft managed to send a more or less useful
Accept-Language header with their Internet Explorer, as does the KDE
team with their Konqueror. You set it more or less with the system
language.
> No doubt. BUT: If you have no other information, it tends to be a bit
> lniguo-centric to presume US English as default.
We don't. We presume the language as default that the users browser
sents in their Accept-Language header. Well, more or less we default to
US English, but only if there is no Accept-Language header, but that is
*very rare* these days.
> As I denoted elsewhere, it would be nice if there was a SSS that covered
> these problems perfectly (chuckle).
Beg your pardon, SSS?
> Not quite. Browsers are oftimes misconfigured;
Don't blame us for misconfigured browsers, misconfiguration must never
be part of a reasoning.
> and at times they can NOT be configured for a correct default (such as
> a library at a multilingual university).
I have never noticed any setup where you can't change the language, and
those are really rare, IMNSHO. At multilangual universities users
usually get their own account on a terminal server or the like and can
of course tweak the settings for the software they use.
> Two distinct and different icon sets that do NOT map 1:1.
> Several languages have that.
Like I said, icons are not a good choice, for they don't work with
textmode browsers. Our content is information related, not graphical.
>> The web page cannot do anything about the browser configuration. All we
>
> Sure it could;
>
> You already do: Text versus pict and slow versus high speeds.
But the web pages can't tweak the browser settings. I don't know what
you mean with slow versus high speeds, what does the web page do about
that? I don't see that. And I don't see what the web page does wrt/
text versus pictures? You mean that we chose to use mainly text on our
page? That is a server thing. Browser settings are a _client_ thing.
> But you would have to get into the realm of JAVA versus ASP versus OS
> versus browser cfg language.
Thanks, please read <http://www.debian.org/devel/website/desc> the part
following the headline "How not to help"[1].
> Only if the browser is theirs to so configure.
> International communities smetimes do not configure a browser for all
> users.
And if they don't configure it for them what makes you think that the
users are allowed to install additional fonts? It's a administrators job
to support their users, not ours.
If they don't have the fonts installed to support their international
users they aren't really an international community, are they?
>> we are trying to get this done as simple as possible so that there is
>> no need for special configuration in the web server (cookies or other
>> session data is *not* used).
>
> Also agreed!
Then I wonder why you came up with Java and ASP above? Sorry, you are
confusing.
>> I do not read or respond to mail with HTML attachments.
>
> You might want ot conside changinng that; I hate format changes too,
> but HTML is now universal ... unfortunately (lousy language and
> braindead that it is).
For mail? Mail is textbased and should stay that way. There is almost
never the need to have a special background or big headlines or making
text red when you communicate with others. Peter most obviously is
addressing HTML mails, not attachments -- I'm sure that he reads them
because he is working on the Debian website, too ,-) (Although we
usually send .wml and not .html files)
So long,
Alfie
[1] Reminds me, we need a toc for that page, to be able to link to #not :)
--
...you might as well skip the Xmas celebration completely, and instead
sit in front of your linux computer playing with the all-new-and-improved
linux kernel version.
-- Linus Torvalds
Attachment:
pgpcG9AeGZu_O.pgp
Description: PGP signature