Re: Considerations on a Multi-Lingual Site - Mailing list pgsql-www

Hi guys,

Are we really the first Open Source Software project to really need an
easy-to-maintain-and-extend-and-be-multi-lingual site?

Would it be beneficial (all good ideas presented here aside) for us to
contact other large projects that have gone before us (perhaps the KDE
project and others?) and find out what they recommend?  Some of them may
be on their 2nd or more iteration of having done this, whereas we'll
kind of be on our first (not counting lessons learnt from the Advocacy
site).

Regards and best wishes,

Justin Clift


Michael Glaesemann wrote:

>
> On Tuesday, November 11, 2003, at 05:31 PM, Andreas Grabmüller 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
>> write the list without knowing HTML...
>
>
> After thinking about it a little more, I realized this is what you were
> talking about—not marking up stuff from the database, getting stuff INTO
> the database.
>
> If a requirement is that the translators don't need to know html, I
> guess I'd go for something similar to wiki markup. Pretty comprehensive
> for the needs of the articles. And CSS let's us keep all the
> presentation markup separate. Just vanilla tags within the proper
> sections lets us style them appropriately.
>
> Ultimately, without having an editor do all the markup, some form of
> markup is going to have to be employed—either html, wiki, or something
> else. An advantage of html is that (obviously) there's no need for a
> special parser. An advantage of wiki is that it might give us a little
> more control over relative headlines. We can define, for example,
> ===Title=== to be <h3> or <h2> or whatever. Of course the html can be
> parsed and the headlines renumbered relative to whatever baseline we
> want. Or just make things really simple, and let <h1> be the headline 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
>> translations, it does not make sense to offer this link to
>> non-translators...
>
>
> Add a flag to translators' cookies that allows them to see the links?
> CSS does allow you to display:none some items, and you could do that via
> a simple JavaScript style switcher, but I don't know how secure that'd
> be, as the links would still be in markup. Might be better just 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
> the articles, rather than have to go through some cms system.
>
>> Currently it's handled so if there's no translation the english
>> version is used - this won't work any more if we don't have an english
>> version, so the question is if the user than gets a 404 - File not
>> 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
>> stored, but I see no reason why we should not allow to store more
>> preferences...
>
>
> And this would get around the "no translation available" problem. The
> article needs to be written in *some* language, and you'd get that if
> nothing else is available, or nothing is higher on your language
> preference list.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>