Standard for client-side recognoition of languages
Philip Trauring
language the user has set for their browser and adapt appropriately.
I'm wondering if there is an equivlent client-side standard for
determining what languages are available on the server. If not, perhaps
we might develop one?
My scenario is this - a user logs onto a web site that is available in
multiple languages - let's say English, French and Spanish. Instead of
the server determining which language to set the site to, the client
will be able to determine that the site is available in those languages
and either set the language accordingly (by loading the appropriate
page, style sheet, whatever), prompt the user if they want to switch
the language, or just indicate to the user in some way that there are
multiple languages available.
The site itself could offer a language-switcher interface, or through
this standard the browser could have a way to switch without the site
needing to have an interface showing on every page. In fact, if the
site can determine that the browser has that feature, it can hide it's
own switching code, and if it doesn't detect that feature then it could
put it's own language-switcher on each page.
Anyone know of something like this that exists? Anyone want to work on
building something like this?
Philip Trauring
coldfusionpaul
in
> multiple languages - let's say English, French and Spanish. Instead
of
> the server determining which language to set the site to, the client
> will be able to determine that the site is available in those
languages
> and either set the language accordingly (by loading the appropriate
> page, style sheet, whatever), prompt the user if they want to switch
> the language, or just indicate to the user in some way that there are
> multiple languages available.
its considered good practice to transparently determine the user's
language (and maybe locale) and offer that language (if you support it
or a fallback one if you don't) AND to provide a manual way for the
user to swap langauges (and no, not those silly flags). manual language
choices should be in those languages (so practically that means using
unicode) and can be something as simple as a select. what you suggest
sounds clumsy, a hiccup in the user's experience with your site.
you can parse the browser's cgi http_accept_language var to get at the
user's preferences or use something like inet locator (geoLocator) at
http://javainetlocator.sourceforge.net/
Paul Novitski
I think you may have misunderstood the remark you're quoting. It didn't
say that the human user would choose the language on start-up, it said the
client would (i.e. the browser). In other words, the software works out
the most likely language and presents that to the user initially, with
links to other the languages available. I believe you and the author of
that quote are on basically the same page.
Should the initial language choice be made by a script on the server or the
client? I've done it both ways and appreciate their respective advantages
& disadvantages. I'm currently working with client-side solutions because
I'm enjoying the instantaneous response time of client-side language
changes, but both work. The HTTP response fields are available to both
client & server.
Cheers,
Paul Novitski
Paul Hastings
i was refering to this bit ("prompt the user "), which i still think is clumsy:
> > > page, style sheet, whatever), prompt the user if they want to switch
> > > the language, or just indicate to the user in some way that there are
> > > multiple languages available.
> Should the initial language choice be made by a script on the server or the
> client? I've done it both ways and appreciate their respective advantages
if you by "client" you mean downloading x number of versions of a
page, i don't agree with that at all. while it might seem fine for
one/two locales & a small bit of content, it won't fly for many
locales/larger amounts of content. i can think of better ways to use
bandwidth than pushing unwanted content at a user. but that's just me.
Philip Trauring
as suggesting that all of those possible implementations should be used
at once. I certainly think the interface should be as seamless as
possible for the user. There's no reason a user should even be aware
that the client determined which version of a page to download.
And those on this list can correct me if I'm wrong, but right now there
is no standard client-side method for choosing languages. If there is,
I was asking that someone might point me to it.
My point is that I think the client-side method has some advantages,
that it would be nice if there was a standard for implementing it, and
that if there was a standard then integration with browsers could be
quite nice (such as a pop-up menu listing all available languages in
the browser window).
Philip
Paul Hastings
> that the client determined which version of a page to download.
kind of hard to do if you're popping up something.
> And those on this list can correct me if I'm wrong, but right now there
> is no standard client-side method for choosing languages. If there is,
> I was asking that someone might point me to it.
perhaps start looking at a "standards" body:
http://www.w3.org/International/questions/qa-when-lang-neg
http://www.w3.org/International/questions/qa-mono-multilingual
> quite nice (such as a pop-up menu listing all available languages in
> the browser window).
why can't something like this work (in a more elegant way of course)?
http://www.sustainablegis.com/projects/i18n/pickLocale.cfm
the idea of a popup forcing a user to do something like pick a
language doesn't sit right with me. i've never done anything like
this clientside, nor have i ever heard of anybody handling it that
way. but again, that's just me.
Philip Trauring
other way needs to interfere with the user? I simply suggested
prompting the user as an option that some might want to use. Note the
use of the word 'or' not 'and' in my list of options for setting the
language.
My main points are that moving the language negotiation to the client
would:
1) Allow language negotiation for sites that can't do language
negotiation on the server side (such as the many sites run on servers
where the user cannot control the web server). There's no reason a web
develop should need to use http negotiation in order to enable language
negotiation.
2) Allow, through the introduction of a standard, browser software to
integrate multi-lingual language selection. This is different than
setting a preference for languages in the following important ways:
a) No preference setting is required. Many people, particularly in
Internet Cafes and Libraries, do not have the ability to change the
browser preferences. There are many many people whose only access to
the net is through public access points.
b) Shows the user (in a pop-up menu placed in the browser UI for
example) in a standard fashion what languages are available for that
page. Important points being that it's 'in a standard fashion' i.e. the
user always knows where to look to find out what languages are
supported, and that since it is client side, the user can know which
languages are available instead of having the version chosen on the
server side.
Philip
Paul Hastings
silly me, i guess your own statement about using a popup fooled me
into you thinking you meant completely the opposite. i won't make that
mistake again.
> other way needs to interfere with the user? I simply suggested
> prompting the user as an option that some might want to use. Note the
> use of the word 'or' not 'and' in my list of options for setting the
> language.
its a "never" as far as i'm concerned.
> develop should need to use http negotiation in order to enable language
> negotiation.
i won't even pretend to understand that.
> a) No preference setting is required. Many people, particularly in
> Internet Cafes and Libraries, do not have the ability to change the
> browser preferences. There are many many people whose only access to
> the net is through public access points.
can be accomplished with a simple manual choice of locale/language on
that website. no need for anything extra. no need to wait for the
browser vendors to agree, etc. you can do it now, no fuss, no muss.
even if this weren't the case, this is something a standards body
should be investigating.
bad example in any case, if folks can't change browser
langauge/encoding preferences they're not likely to be able to d/l
fonts, etc. that would be required to view locales/languages not
already set in the browser preferences.
> b) Shows the user (in a pop-up menu placed in the browser UI for
> example) in a standard fashion what languages are available for that
why bother? you can easily do it as i've stated above. and again
there's that phrase "pop-up". make this part of UI & be done with.
> languages are available instead of having the version chosen on the
> server side.
that will always be the case, you have to start with something. even
if its just to push a bunch of js goop & x number of language versions
at a client. its much cleaner to deliver a locale/language--chosen
some way--and then provide a way for the user to swap to another
locale/language as they require.
Philip Trauring
is to give the user a consistent interface for selecting which language
to use.
Right now you are saying the way things work is that you need to
specify your language in the browser preferences, get your initial
language set via http negotiation (assuming the web site supports that)
and then allow the user to change their language through a
language-switcher on the web page.
I'm saying set the language preferences the same way, but have the
client determine which language to load by looking at the code of the
page, seeing what's available, and switching if necessary. The same
block of code can visually allow the user to switch languages if they
desire.
So whether that interface is in the web page or in the browser, or even
both (and certainly if there was a standard the browser could remove
the language-switcher in the web page if it offers it's own interface)
it should be consistent across many different web sites. A Standard. I
know you can make your own language-switcher interface and I know many
of the people on this list can do the same. I think, however, that
users would like to see a consistent interface for such
language-switcher interfaces and that is all I am proposing. And - like
I said above - if the browser does support this standard, you can
remove the unneeded language-switcher from taking up extra space on
your page.
Lastly, there are many different techniques for switching between
languages. Each person here has probably coded up a slightly or very
different way of switching languages. Some might use databases, some
XSLT, some alternate HTML files - each has it's advantages. What a
standard would allow is to codify many different techniques, but allow
a single interface to operate them. So whether the web developer
chooses to use a database, choose to pull translations out of an XLIFF
file using PHP, or choose to just switch to a translated page or a
different directory, the user won't need to know any of this - they
will still see a consistent interface. And if there is a standard, the
browser company can eventually build support for it, but that won't be
necessary.
Creating a standard might include defining that a div with the ID
"langswitcher" supports the language switching code, forcing or
suggesting that the div be positioned in a specific place on the page,
choosing which let of language names to use (like perhaps ISO, but
perhaps not since they're talking about charging people to use their
language codes)
Philip
On May 27, 2004, at 3:31 PM, Paul Hastings wrote:
>> Why do you keep insisting that my idea requires a pop-up or in any
>
> silly me, i guess your own statement about using a popup fooled me
> into you thinking you meant completely the opposite. i won't make that
> mistake again.
>
>> other way needs to interfere with the user? I simply suggested
>> prompting the user as an option that some might want to use. Note the
>> use of the word 'or' not 'and' in my list of options for setting the
>> language.
>
> its a "never" as far as i'm concerned.
That's nice, but I think the user should have the choice to decide how
they are informed. If they want something to pop-up when they get to a
web page that offers multiple languages, let them. They might want a
flag in the corner of the browser window to flash. They may want a
window to pop up. Who cares? Let them choose.
>> develop should need to use http negotiation in order to enable
>> language
>> negotiation.
>
> i won't even pretend to understand that.
Not complicated - you shouldn't need to support http negotiation in
order to offer language switching. My proposal eliminates the need for
http negotiation by switching control to the client.
>> a) No preference setting is required. Many people, particularly in
>> Internet Cafes and Libraries, do not have the ability to change the
>> browser preferences. There are many many people whose only access to
>> the net is through public access points.
>
> can be accomplished with a simple manual choice of locale/language on
> that website. no need for anything extra. no need to wait for the
> browser vendors to agree, etc. you can do it now, no fuss, no muss.
> even if this weren't the case, this is something a standards body
> should be investigating.
Standards get to standards bodies when people organize themselves and
submit something. I am suggesting that those people on this list, if
they are so inclined, can contribute to such a standard for submission
to the relevant standards body.
> bad example in any case, if folks can't change browser
> langauge/encoding preferences they're not likely to be able to d/l
> fonts, etc. that would be required to view locales/languages not
> already set in the browser preferences.
Who said anything about downloading fonts? Some day in a CSS3 world we
will be able to offer that automatically, but I wouldn't touch that
with a ten-foot pole today. I think it's safe to say that if I was in
an Internet Cafe in Japan, where they had set the language preference
to Japanese, that they would still have a Roman font on the computer
for me to use since I speak English. Many computers come with multiple
character sets available to them - mine came with English (Roman),
Japanese, Chinese, Cyrillic, Hebrew, Arabic and I think Malay. That
might be above the average, but I think it's safe to assume that at
least on computers that use non-Roman character sets as their default,
they at least have a Roman font on their system - or they wouldn't be
able to get to most web sites today.
>> b) Shows the user (in a pop-up menu placed in the browser UI for
>> example) in a standard fashion what languages are available for that
>
> why bother? you can easily do it as i've stated above. and again
> there's that phrase "pop-up". make this part of UI & be done with.
Boy you really need to read before you write. Note the 'for example'. I
could suggest a dozen other UI options for that. It's besides the point
how it looks in the UI.
>> languages are available instead of having the version chosen on the
>> server side.
>
> that will always be the case, you have to start with something. even
> if its just to push a bunch of js goop & x number of language versions
> at a client. its much cleaner to deliver a locale/language--chosen
> some way--and then provide a way for the user to swap to another
> locale/language as they require.
Yes, there will always be a default language. So? How languages are
chosen if the default language doesn't match the user's preference is
what's under discussion here.
Paul Hastings
> is to give the user a consistent interface for selecting which language
> to use.
i'm only repsonding to what you wrote. i don't agree with it.
> Right now you are saying the way things work is that you need to
> specify your language in the browser preferences, get your initial
never said that.
> language set via http negotiation (assuming the web site supports that)
> and then allow the user to change their language through a
> language-switcher on the web page.
thats what the standards body is saying.
> I'm saying set the language preferences the same way, but have the
> client determine which language to load by looking at the code of the
> page, seeing what's available, and switching if necessary. The same
thats what would be happening, just not clientside. adding something
clientside, especially something that interferes with the flow of the
user experience just doesn't do it for me, and adds extra, and i
contend uneeded, complexity.
> it should be consistent across many different web sites. A Standard. I
> know you can make your own language-switcher interface and I know many
> of the people on this list can do the same. I think, however, that
> users would like to see a consistent interface for such
then propose a style or something, not that anybody would pay any
attention. i see so many sites using flags or not using localized
language pickers that it seems like users don't actually care, see the
globalization blog for some stories: http://www.bytelevel.com/blog/ i
just don't agree with your idea.
> different way of switching languages. Some might use databases, some
> XSLT, some alternate HTML files - each has it's advantages. What a
thats language content, switching is still switching.
> different directory, the user won't need to know any of this - they
> will still see a consistent interface. And if there is a standard, the
sounding like a broken record, "they can get this now".
> Creating a standard might include defining that a div with the ID
> "langswitcher" supports the language switching code, forcing or
> suggesting that the div be positioned in a specific place on the page,
now you're talking style/design. i think nobody's going to agree to
that as some webstandard, at least not formally. but prove me wrong,
get w3c to look at this idea, at least put it to the mailing list.
> choosing which let of language names to use (like perhaps ISO, but
> perhaps not since they're talking about charging people to use their
> language codes)
not any longer.
Philip Trauring
client-side language selection. How about everyone else?
Philip Trauring