Date: Wed, 12 Nov 2003 02:35:02 +0900
Subject: Re: Considerations on a Multi-Lingual Site
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: pgsql-www@postgresql.org
To: <webmaster@letzplay.de>
From: Michael Glaesemann <grzm@myrealbox.com>
In-Reply-To: <20031111083136.29826.qmail@osiris.gamecrashnet.de>
Message-Id: <615FF68C-146D-11D8-9A55-0005029FC1A7@myrealbox.com>
Content-Transfer-Encoding: quoted-printable


On Tuesday, November 11, 2003, at 05:31 PM, Andreas Grabm=FCller wrote:
>> This doesn't solve the problem of how you get the list into the
>> database, but that shouldn't be too hard.
>
> Well, the problem I see is that we need a way for the translators to=20
> write the list without knowing HTML...

After thinking about it a little more, I realized this is what you were=20
talking about=97not marking up stuff from the database, getting stuff=20
INTO the database.

If a requirement is that the translators don't need to know html, I=20
guess I'd go for something similar to wiki markup. Pretty comprehensive=20
for the needs of the articles. And CSS let's us keep all the=20
presentation markup separate. Just vanilla tags within the proper=20
sections lets us style them appropriately.

Ultimately, without having an editor do all the markup, some form of=20
markup is going to have to be employed=97either html, wiki, or something=20
else. An advantage of html is that (obviously) there's no need for a=20
special parser. An advantage of wiki is that it might give us a little=20
more control over relative headlines. We can define, for example,=20
=3D=3D=3DTitle=3D=3D=3D to be <h3> or <h2> or whatever. Of course the html =
can be=20
parsed and the headlines renumbered relative to whatever baseline we=20
want. Or just make things really simple, and let <h1> be the headline=20
of every article, and define the style of h1 (and others) via CSS.

>> I could see a link with something like "Translate this item" if a
>> translation isn't available in the preferred language of the viewer.

> Difficult - except we want to give everyone access to the=20
> translations, it does not make sense to offer this link to=20
> non-translators...

Add a flag to translators' cookies that allows them to see the links?=20
CSS does allow you to display:none some items, and you could do that=20
via a simple JavaScript style switcher, but I don't know how secure=20
that'd be, as the links would still be in markup. Might be better just=20
to completely leave those links when building the page.

I'm just trying to think of an easy way for the translators to get to=20
the articles, rather than have to go through some cms system.

> Currently it's handled so if there's no translation the english=20
> version is used - this won't work any more if we don't have an english=20
> version, so the question is if the user than gets a 404 - File not=20
> found message or the content in a different language...
>
>> It might be nice if you could store a language preference order in the
>> cookie. So for example, if I wanted English first, then German, then
>> Japanese, I'd get the translation of the highest preference that was
>> available.
>
> Should be possible. Currently just the one prefered language is=20
> stored, but I see no reason why we should not allow to store more=20
> preferences...

And this would get around the "no translation available" problem. The=20
article needs to be written in *some* language, and you'd get that if=20
nothing else is available, or nothing is higher on your language=20
preference list.