Dallas33,
What you want to do is called content negotiation. This applies to
both languages and file types. It can be a nifty thing to do for an
internationalized site, but it does require a lot of work and planning
to make it effective.
<<If a customer clicks a link to my website, is there information that comes
with the transmitted HTTP request that could be used for me to know
what her preferred language is -- or at least what her geographic
locale is? >>
Yes, it is the HTTP accept-language header.
Accept-Language section of the W3C standard:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
<<What is the nature of that information?>>
It appears in the form of a language tag or tags, such as "en-us" for
English-United States. It can also be a list of tags with degree of
preference.
Language Tags section of the W3C standard:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10
<<How reliable would it be that such information would come with the request?>>
Most modern browsers provide it automatically, however, you should
always provide an alternate method of language selection, in case the
browser is incorrect, or does not provide enough information. Also,
the user can clear their language list to prevent a preference from
being sent. You should always have a default handler to deal with not
receiving a language preference.
<<How often would it be accurate?>>
It depends on a number of factors. Most people don't bother checking
to see if their language preferences are set correctly, so it depends
on how well the browser guesses at setup time. Most modern browsers
guess based on locale.
If set, it should be fairly accurate unless someone browsing from a
computer in Germany and only speaks French, for example, an Internet
cafe. In this case, however, the user can manually tell their browser
to prefer French. Again, you should always provide an alternate method
of language selection, in case the browser is wrong.
<<Can you answer these questions and give me an authoritative
reference to show my Web programmer?>>
Below is a link to the W3C FAQ on this topic. W3C is the standards
organization. The link includes information, a discussion of the
potential issues and links to additional information.
http://www.w3.org/International/questions/qa-accept-lang-locales#background
The link below is a page by Alan J. Flavell with notes on implementing
content negotiation and some of the issues involved.
http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html
Below is a link to the documentation for one way to implement this
using the Apache web server.
Apache Content Negotiation
http://httpd.apache.org/docs/content-negotiation.html
I hope the information provided answers your question. If not, please
request clarification.
- Hammer
Search strategy
----------------
"content negotiation"
"accept-language" header HTTP |
Request for Answer Clarification by
dallas33-ga
on
31 Jan 2005 07:13 PST
Hammer:
Thank you for your answer. I have used your information in writing
about a method that I argue will be an improvement over existing art.
If you know of information to add (or of corrections) I should make to
my writing (especially to bolster my arguments), your added feedback
would earn my thanks, high rating, and tip:
In the present application the method disclosed for language
accommodation is highly reliable and automatic. Furthermore, it is
highly transparent in providing said accommodation and, thus, achieves
an important goal of allowing a manufacturer not to seem "foreign" to
a buyer. (Buyers tend to shy away from international ecommerce for
many understandable reasons.)
Experts on internationalization of websites do not judge prior art in
this area as able to provide a reliable and automatic solution to the
problem of accommodating to a customer's language. The typical
"workaround" is to guess at the preferred language by using HTTP
accept-language header information. (See
http://www.w3.org/International/questions/qa-accept-lang-locales#background.)
However, experts teach that approach is NOT reliable and should be
backed up by offering the customer the opportunity to select a
preferred language after a page is transmitted. At that point, the
workaround fails important goals of being automatic and transparent.
(See http://www.w3.org/International/questions/qa-accept-lang-locales#answer
and http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html.)
Furthermore, that workaround runs into a chicken-and-egg paradox
because a language must be selected that can communicate the offer to
change the language. In any case, the workaround, in order to gain
some reliability in presenting a preferred language, becomes neither
automatic not transparent. Therefore, it is inferior and in no way
equivalent to the automatic, reliable, and transparent solution
offered in the present application.
|
Clarification of Answer by
hammer-ga
on
31 Jan 2005 07:53 PST
Dallas33,
Please clarify for me the intent of your argument. You've provided a
piece from the middle, and I want to be sure I understand your intent.
It appears that you are arguing *against* using the accept-language
header in favor of a process that you have developed and already have
in place which uses a different method to present pages in an
appropriate language.
Am I reading this correctly?
- Hammer
|
Request for Answer Clarification by
dallas33-ga
on
31 Jan 2005 19:25 PST
Hammer,
Exactly.
The part you are not seeing is a description of an invention for
improved internationalization of ecommerce. Because I have not yet
received a patent for the method, I am avoiding disclosing it.
What I need to present is an argument that my method is an improvement
on prior art for internationaizing ecommerce. Is there anything that
you suggest that I add to (or correct in) my written argument that
prior art fails in several significant ways -- being reliable,
automatic, and transparent?
Thanks again.
|
Clarification of Answer by
hammer-ga
on
31 Jan 2005 20:13 PST
Dallas33,
Now that I understand your goals, I've made some recommendations on
your provided text. Below are some additional points and some
rewording of your text to use as you see fit. I've also included notes
on the reasons for the recommendations. Be aware that I'm working
through a keyhole on this. I've provided my observations for you to do
with as you choose. If anything in there is valuable to the overall
goal, use it. If not, don't!
I hope this helps. Please let me know if you need anything further.
- Hammer
--------------------------------------
The current method of accomplishing internationalization of websites
relies on use of the HTTP accept-language header. (See
http://www.w3.org/International/questions/qa-accept-lang-locales#background.)
This header is passed to the web server by the browser and is intended
to indicate the language preferred by the user. However, this method
relies on two heavily flawed assumptions.
The first flawed assumption is that any one computer is used by only
one user. While this was once a safe assumption, a significant
increase in shared and publicly available computers now means that
many computers are used by multiple users. This means that, while any
one user may set the language preference reported by the browser, that
preference may not be correct for other users.
The second flawed assumption is that the location (or locale) or the
computer is an accurate indicator of the primary language of the user.
This is simply not the case. Multilingual households, multilingual
offices, public libraries, internet cafes and airport kiosks are all
examples of situations where the location of the computer may not
accurately represent the primary language of the user. In addition, in
the examples above, lack of technical knowledge and/or interface
restrictions may prevent the user from resetting the browser to
accurately reflect their language preference.
Because website designers are aware of these issues (See
http://www.w3.org/International/questions/qa-accept-lang-locales#answer
and http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html.), an
effective internationalization implementation requires that the
customer be offered the opportunity to manually select their preferred
language if and when the browser fails to accurately reflect their
language needs. At that point, the current method fails the important
goals of being automatic and transparent. Even in a well-implemented
site, the customer must visually scan the page for something in a
language they recognize in order to get off the incorrect track
selected by the browser. Therefore, it is inferior and in no way
equivalent to the automatic, reliable, and transparent solution
offered in the present application.
---------------------------------------
NOTES:
1. I've added some language regarding the out-of-date assumptions
driving the current standard.
2. You refer to using the accept-language header several times as a
"workaround". As W3C is the standards organization, designers using
this header are following the intended standard. I'm not sure it's
appropriate to call it a workaround. The issues with the current
method are real enough that I feel you don't have to exaggerate them.
In my opinion, not doing so increases your credibility.
|
Request for Answer Clarification by
dallas33-ga
on
01 Feb 2005 08:25 PST
Yes, credibility is very important. I will use the word "workaround"
judiciously, if at all, in the final draft for my project.
My final draft will run around 10 pages, single-spaced. It could
probably benefit from having somebody like yourself look at it with an
editor's eye. Is there some way you can be available for that kind of
work that would be more confidential than going through this service?
I will be giving you the highest rating for your help here. Can you
tell me how I go about posting an extra amount as a "tip" for your
excellent service?
|
Clarification of Answer by
hammer-ga
on
01 Feb 2005 09:20 PST
I'd like to help you, but Google Answers Researchers are not permitted
to have direct contact with customers.
If you do want to post your draft for review, one of the other
Researchers can look it over for you.
Thank you for the rating, nice comment and tip!
- Hammer
|
,
0 Comments
)