Re: Web pages/Debian/languages: Great!
Some I agree with, most I do not. See below. Thanks for the response.
Keep up the good work. At least consider placing the language names in columns, alphabetized (or std order) by name.
In a message dated 2003/08/27 08:59:21 Eastern Daylight Time, firstname.lastname@example.org writes:
Subj: Re: Web pages/Debian/languages: Great!
Date: 2003/08/27 08:59:21 Eastern Daylight Time
CC: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Sent from the Internet
>I) It might be better to have language references at the TOP of the
>structure instead of the bottom.
That would take up too much room at the top of the page, which would
require you to scroll down to read every single page. I doubt that
would be a good idea.
Reading further down in my EMail, you would see the recommendation for a "brief" form in a standard location, by icon;
that would NOT take up too much space.
>II) A standardized presentation in minimal form would be better, to
>minimize the space taken up.
The name of the language, IMHO, *is* the best representation of the
language, since it is guaranteed to be understood by the reader.
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.
> A) A right click (or other launch method) for a drop down menu to
Drop down menus are obscure, and take place to find. You'll also need
to know that you can find your language there to start looking.
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.
> B) Country flag icon, Language icon, plus country name and language
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.
This type of handicap is quite common. Including among competent IS/IT people ...
> C) Presentation in the language currenlty in as well as the
>language going to (including ordering as expected inn that language)
>by each column [country or language]
The main representation must always be in the target language, since
you are about to switch *to* it. It is completely useless for me to see
That it should be present can be debated, but it is easy to see that it is useful;
please note I did not state main or other versus presentation alternative; merely denoted
the usefulness of other ones _besides_ the native one.
the word "Suèdois" on a French page if I don't know that that is the
word for "Swedish". Anyway, the language name in the *current* language
If you cannot read the "from" language you wil have a hard time understanding English
"from" text describing to point and click on a single word in the middle of a list of
other words that do NOT reside in your native language; so your point is marginal at best.
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.
*is* available, it is used as the link title, just hover the mouse over
the language link and you'll see it.
Only if you know to hold the poniter there; bas to presume without describing; the default form should present it explicitly;
otherwise why have a "dumb" versus "smart" (or "naive" versus "expert") form in the first place?
I thought I mentioned seeing the pop up name; sorry if I did not.
> ^) Do you default by IP address to country of origin or other
>content negotiation standard?
IP addresses are also a poor choice for selecting languages. Currently,
If no other information is present, it probably is the best choice available.
that would give me French pages, although I cannot read that language.
The more pertinent kvetch-ion(s) is(are)
[a] how many people on the web world wide would get the correct language?
[b] How many sessions (per-use statistic) world wide would get the correct language?
[c} How many viewers and per sessions who _use_your_website_ would get the correct language?
... not whether _you_ would get the correct one or not.
This is moderated by what expected conventions, protocols, and sop forth are commonly in use ...
so as not to contradict them.
Several big European cable tv ISPs are known to use the "wrong" IP
ranges for their customers. Also, many countries are bi-lingual.
No doubt. BUT: If you have no other information, it tends to be a bit lniguo-centric to presume US English as default.
As I denoted elsewhere, it would be nice if there was a SSS that covered these problems perfectly (chuckle).
The only variable used to determine the language for the pages is the
setting for preferred language in the web browser, as this is the only
setting that is reliable.
Not quite. Browsers are oftimes misconfigured; and at times they can NOT be configured for a correct
default (such as a library at a multilingual university). Long discussion.
> 1) Japanese, two iconographies
What do you mean?
Two distinct and different icon sets that do NOT map 1:1. Several languages have that.
Even those that have (a) a native alphabet or iconography, and (b) an English transcriptive altenative
many times do NOT have the same mapping character to character, much less icon to icon.
> H) You migt want to consider adding drop down menus (with
>alternates) for browser configuration to be done automatically by the
>server (or at least to build a complete script or instruction file
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 you would have to get into the realm of JAVA versus ASP versus OS versus browser cfg language.
Versus permissions and privileges.
Might not be worth the risk to do the effort.
That was why I suggested either building a script or customizing instructions basd on menu selections.
Which in turn might not be worth it until the international community gets more widespread penetration. Sadly.
can do is provide instructions on how to use it - which we do
> I) Places to get fonts and so forth for each manguage would be useful.
People that read a language would usually already have configured their
computer to display it, so that is not necessarily very important.
Only if the browser is theirs to so configure.
International communities smetimes do not configure a browser for all users.
>III) It would REALLY be nice of this was in a standardized place
>according to some standardized SSS (Schema Specified Somewhere).
There is support for things like this in the HTTP protocol, we use it,
Great; like I said, good work!
but since it doesn't always work 100%, we also have the language
selection at the bottom of the pages as a fallback. Also remember that
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).
Peter - http://www.softwolves.pp.se/
I do not read or respond to mail with HTML attachments.
Does that include HTML main mail, or just the attachments? How about non-text 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).
CHeers. (go back to the more important stuff ...)