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 :) * [EMAIL PROTECTED] [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, > [EMAIL PROTECTED] 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
pgpbxHCIGH4Xw.pgp
Description: PGP signature
