RFC 3282, start the discussion
Manfred Stienstra
You've had three weeks to gather your notes. Please start discussing
RFC 3282.
Manfred
Manfred Stienstra
Lately I've been localizing a few web applications so I picked RFC
3282 because I wanted to think about language negotiation. The
standard in itself isn't very special, it defines a mechanism very
much like the Accept/Content-Type headers, but maybe there are some
posibilities?
Most browsers seem to support it in one way or another. Firefox has a
configuration option for your preferred language and sends 'en-
us,en;q=0.5' by default. Safari doesn't offer any configuration
options for the Accept-Language header and seems to use the system
wide language default (does anyone have a non-English version to
confirm this?). In my case Safari's language is 'en'.
Apache has support for the Accept-Language header bundled together
with support for the Accept header in mod_negotiation since forever. I
couldn't find support in other servers, although I haven't searched
very thoroughly (does anyone have more information about this?).
I have the feeling that there aren't many web applications responding
to either the Accept or Accept-Language header. My applications all
use a language code in the URL to return the content in the preferred
language. Google redirects me to google.nl by default, probably based
on my IP address. So why isn't it natural to support the Accept-
Language header?
Most desktop applications use some sort of localization framework, and
RFC 3282 can be seen as a basis for a language localization solution
on the web. The reason it's not used much in the wild is probably that
preference follows availability, not the other way around; imagine
your mother tongue is French and you happen to know a little bit of
German and Spanish. When you're visiting a native Spanish site that
doesn't offer a French translation, you might prefer Spanish over
German and the other way around on a native German site. A good reason
for this is that a translation is always less desirable then the
original language because details from the original text might have
been lost.
In short: RFC 3282 doesn't offer you a way to present language
alternatives for a resources / group of resources.
I do see one application for Accept-Language, and that's serving
static 403, 404, 500 etc messages. Right now most of my localized
applications send either Dutch or English error messages to all users,
regardless of their language preference set in the application. I
guess using the Accept-Language header is better than nothing in this
case. Safari seems to send the language of the operating system, and
we can assume the user is able to understand this.
Manfred
Thijs van der Vossen
> Lately I've been localizing a few web applications so I picked RFC
IMHO the introduction is a classic example of geek humor:
"There are a number of languages presently or previously used by
human beings in this world.
A great number of these people would prefer to have information
presented in a language which they understand."
Can you get any more obvious? :)
Kind regards,
Thijs
--
Fingertips - http://www.fngtps.com
Thijs van der Vossen
> Language header and seems to use the system wide language default
> (does anyone have a non-English version to confirm this?). In my
> case Safari's language is 'en'.
Go to System Preferences > International and reorder your languages.
With 'Nederlands' as the first preferred language Safari sets the
Accept-Language request header to 'nl-nl'.
There's no such thing a a non-English version of Mac OS X; all
supported languages are always included unless you remove them yourself.