Re: PostgreSQL website translations

On Mon, Mar 10, 2008 at 11:49 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> 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.

When an English page is modified we could :
- immediately send a notice to the translators.  Automatically added Trac
tickets seem to be a cool idea if it's possible.
- keep displaying the old translated page for 4-5 days
- if the translation is not yet ready we could invalidate the
page : move it somewhere else and start displaying the
English page until the translation is ready.
Or, instead of moving away the page we could add an
"outdated page since yyyy-mm-dd" warning .

Either way , I think that it would be better to give the translators
a few days to do the update before hiding or marking the page.


But first of all,  we'll need a good way to store the last_modification_date
for each page : each page (English and translations alike) need to
be "stamped"  with a date or date+time .   The date of the svn
revision is not good enough because relying on it is the perfect
recipe for missing modifications if they are occuring before the
translators finishes the translation of a previous version.

Here is a scenario :
- 8-apr: the English page is modified+committed
- 8-apr: the translator starts translating
- 9-apr: the English page is modified+committed again
- 10-apr: the translation gets committed (but it has the contents for 8-apr)

So,  I think that we'll need to build some mechanisms for dealing
with the page versions/trabslations outside of what does svn offer.


Cheers,
Adrian Maier