[Women-website] Language Negotiation and charsets

[Jutta Wrage]

--Apple-Mail-27-944384475
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi!

Am Samstag, 02.04.05 um 00:17 Uhr schrieb Thierry Reding:

> That is not true. Due to content negotiation, the user will always be
> redirected to the negotiated language at the first page access (unless 
> they
> access a specific language URL already). I.e.: if you access
>
>     http://women.alioth.debian.org

Then, yes. But if you make a google search, you will not go back to 
your language automatically.

>> Tierry's suggestion:
>>
>> fo.en.html links to bar.en.html
>> fo.de.html links to bar.de.html - which might not exist: Error 404
>
> This would happen if we do that the lazy way, which we won't, right?

Hmm... So everyone translating a single page would have to search for 
all links. And if the main page is not translated? Who will have the 
overview? What do you think is the reason why the debian pages are 
working the way they do? Because they are built respecting standards.
And the women project should work the same way.
There are thousands of people visiting the debian pages. But only very 
few have ever complained about that correct behaviour. Most of them 
only had the problem not to know how to set up language negotiation 
correctly.


> For instance:
>
>     You are currently looking at the Spanish involvement page. From 
> there,
>     there is a link to the IRC FAQ, which exists in Spanish. So the 
> link goes
>     to 'ircfaq.es.html'. On the same page, there is a link which goes 
> to the
>     profiles page, which does not exist in Spanish. That link should 
> contain
>     '../profiles' or '../profiles/index', thus giving you the page in 
> the
>     best negotiated language.

Please. please, tell me, what all that additional work should be good 
for?
Who else than someone reviewing pages in a foreign language to see, if 
they work, will need that?
The site will have lots of broken links and unlinked pages, soon.

>> normal behavior:
>> foo is called as foo by the visitor.
>> foo.de.html links to bar -> user gets bar.html instead of an error if
>> the german page does not exist (or any other existing language in 
>> order
>> his preferences in the negotiation.
>>
>> That is how negotiation works
>
> I am not saying that this is not how content negotiation works. 
> However I do
> not believe that it makes sense at all to provide a "language 
> switcher" which
> switches only the current page,

You may leave out the switcher (whereas they are useful to see, in how 
many languages a page is translated already), but you may _not_ link 
directly if you want to care standards.
URLs should be something readable and users should not have to care 
about the differences between foo.de.html, foo.de, foo.html.de, 
foo.php, foo.de.php. The should be able just to type in "foo"

>  and switches back to the negotiated language
> for the next page again. I don't think that would be much of a switch, 
> then.

It is a way to find the current page in a special language without 
knowing, which of the URLs above it is.

> I do not see why anyone would want to have it this way either. The 
> only case
> I can think of where this behaviour might actually be useful is for 
> testing
> purposes, and thus should not be included on the page anyway.

As said: we do not need, but we should not have the pages directly 
linked by language instead. If there is a link to bar on foo, the link 
should point to bar and not bar.en.html or bar.html.en or something 
else.

greetings

Jutta

-- 
http://www.witch.westfalen.de
http://witch.muensterland.org


--Apple-Mail-27-944384475
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAkJNz0AACgkQOgZ5N97kHkfE6QCgs+xIefNyjaNT9IPLRNj1JKKU
f/MAoJebvPWQAGwTHxMWNgRf+eMwRGzO
=hN+n
-----END PGP SIGNATURE-----

--Apple-Mail-27-944384475--