In particular, we want the webpage to respond to the browser's language
preference. That means the user gets a page s/he can read, not a jumble
of meaningless symbols. (To experience this, try going to a page written
in an alphabet you can't read.)
This is important, for example, because the OpenOffice.org Help,
regardless of translation, points users to the English mailing lists,
Wiki, FAQ and forum. You can't localize that information: gsicheck won't
allow it.
How far have we got towards effective content negotiation?
I can only comment on the Wiki :-) Content-negotiation is not set up on
the Wiki server.
For those that don't know, content-negotiation is an Apache2 mechanism
you can use to serve web pages (if available) in the language
preferences provided in the browser request string. This is the
"proper" way to do this over the more common Geolocation which simply
assumes that if you are connecting from an IP in a certain country you
must speak/read the local language (one I get dinged by all the time
from speaking/reading English, but living in Germany).
On the Wiki, if you are a registered user, and set your language, then
the Wiki interface should be in the language you set in your
preferences. It will default to English though for unregistered viewers.
For content pages that are translated, the InterWiki links feature is
working now. If people start using this feature, then when a page is
available in another language, the "In other Languages" box on the lower
left will have the language name in the characters of that language.
I am not sure if MediaWiki can use content-negotiation... I can look
into it. If anyone knows how this can be set up for MediaWiki, then
please speak up :-)
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
