Re: PostgreSQL website translations - Mailing list pgsql-www

From Magnus Hagander
Subject Re: PostgreSQL website translations
Date
Msg-id 20080310094928.GH30980@svr2.hagander.net
Whole thread Raw
In response to Re: PostgreSQL website translations  ("Adrian Maier" <adrian.maier@gmail.com>)
Responses Re: PostgreSQL website translations  ("Adrian Maier" <adrian.maier@gmail.com>)
List pgsql-www
On Mon, Mar 10, 2008 at 11:32:28AM +0200, Adrian Maier wrote:
> On Sun, Mar 9, 2008 at 1:00 PM, Magnus Hagander <magnus@hagander.net> wrote:
> >
> >  > Despite the lack of answer, I think there is interest in translating the
> >  > website. But there's a few things to do before adding the translation. I
> >  > need to remember what Magnus told me about this last november :) ( ...
> >  > if I remember well, I had to find some way to figure out if pages are
> >  > out of date and if possible show the english page if the translated page
> >  > is out of date ... something like this but Magnus will correct me if I'm
> >  > wrong). Oh, and the pictures need to be "translatable" too.
> >
> >  My apologies for not responding to this one earlier. It's certainly bee
> >  on my list to do.
> >
> >  I think what we really need before we can proceed properly with this is
> >  a "www code hacker" who can work the translation code. Not just a
> >  translator (don't get me wrong, we need a bunch of translators as well
> >  of course). Someone who can basically take responsibility for fixing up
> >  the code to work with the translations. There are a lot of small things
> >  broken in it AFAIK, and they need to be fixed. Guillaume mentions a
> >  couple of them, I think there are a few more. And some sections just
> >  don't have translatability implemented (yet).
> >
> >  There's no rocket science level code in the website, but said someone
> >  certainly needs to have a fairly good grasp of PHP and of coding in
> >  general. And most important - needs to have time to work on it.
> >
> >  As usual, this is best done in an incremental fashion rather than
> >  dumping a mega-patch in there - it'll be much more likely to be reviewed
> >  and applied quickly then.
> >
> >  But in the end, I think there is certainly interest in doing it. The
> >  reason the "current web team" is a bit slow on this is that we don't
> >  have what it takes to maintain such things once they are in right now -
> >  which is why we need someone to step up for the long term there. (IMO,
> >  of course, other members of the team may disagree on this, but I don't
> >  think they do)
> 
> Shame I didn't know 6 months ago that there are little chances to
> have a translation accepted before certain things are adjusted in
> the web infrastructure first :  i had plenty of time last autumn and
> winter. And instead of translating the already outdated pages and
> receiving no feedback I could have digged into the PHP parts of
> the site ...

Yeah, apoligies for that. I think it was kind of implied, but we never did
spell it out. Which we should've. 



> Starting from 24 march i'm changing the job,  so it's hard to predict
> how much spare time shall I have.  How many hours per week do you
> think someone would need for taking care of the translation-related
> issues of the website ?

I don't think it'll be all that much, really. What's needed is a "big push"
to get things ready in the first place, and that's going to take quite a
bit of work. Once that's there, the main ongoing work will be updating
translations. There's almost no time spent "maintaining" the PHP code for
the main site when there aren't new features added, and I expect the same
thing for the translation stuff. However, everytime we add new features and
such, it has to be handled.


> Perhaps it would be useful to have the things that need to be fixed
> added on Trac ?

That's a very good idea. First we just have to agree on what they are :-)

I think one big question that we never did solve the last time is what to
do with pages that are out-of-date. E.g. when the english version of a page
is updated, and the translated one isn't, what do we do with it... Show it
anyway, remove it, somehow indicate it... Once we've decided what we want
to do about it, then we can start debating how to do it (which is where the
point of cvs/svn etc comes back in), and start adding tickets for them.

//Magnus


pgsql-www by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Contributor listing policy
Next
From: "Adrian Maier"
Date:
Subject: Re: PostgreSQL website translations