Re: PostgreSQL website translations

On Mon, Mar 24, 2008 at 12:26 AM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Adrian Maier a écrit :
> > On Mon, Mar 10, 2008 at 1:13 PM, Guillaume Lelarge
> > <guillaume(at)lelarge(dot)info> wrote:
>
> >> I don't think we need to move the obsolete translated webpage. The PHP
> >> code should simply display the english one.
> >
> > Ok , that's fine with me : the English page replaces the translated page
> > until the translator updates it.
> >
>
> Well, I'm not so sure now. For someone who doesn't speak english, an old
> translated page could be better than the current one in english. I mean,
> there's no need to have an uptodate translation of the books webpage for
> example.
>
> Probably we can do the same as the Debian guys : add some text on the
> translated webpage which can specify that a more up to date page is
> available in english and can be found "here".
>
> >>[...]
>
> >> > 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)
> >> >
> >>
> >> Oh OK. I understand your example. But if we can't rely on a svn hook to
> >> stamp each file, I also don't think we can rely on a manual
> >> modification, do we ?
> >
> > The core of the problem is finding a good place to store the
> > correspondance between a given page and its translations.
> >
> > My point is that we need a way to store information like
> > "ro/about/advantages.html rev5001 (10-apr-2008) is the translation of
> > en/about/advantages.html rev4995 (8-apr-2008) " .
> >
> > It's excellent if this can be achieved with svn hooks , but I doubt that
> > it's possible.
> >
>
> I doubt too. And, really, I don't think we need this much of a system.
> Your example is quite interesting but how many times will we have this
> issue ? I don't think many times.

It would happen frequently enough to give headaches to any translator
who is trying to add a new language . At least until the new translation
is accepted and committed.

> Perhaps we should just trust the
> translator. Before commiting his stuff, he needs to check if someone
> else changes the webpage. Trusting the translator will simplify the
> issue of the obsolete page. We'll simply need to check the modification
> date to decide if the website should display the translated one or the
> english one.

I don't think that the existing tools (svn) is enough to make the life
easy for the potential website translators.

I like and use svn daily, but this doesn't mean that it's the right tool
for handling translations ...

> >> > So, I think that we'll need to build some mechanisms for dealing
> >> > with the page versions/trabslations outside of what does svn offer.
> >>
> >> Do you have any ideas of what this could be ?
> >
> > I'm dreaming of having "something" (some scripts or maybe
> > or even a web application for translators) that gives:
> > - the list of pages that need to be modified or that are new
>
> Easy to write a script that does just this if we agree on the
> "modification date check".
>
>
> > - for each listed file :
> > * the diff between the "English text that was translated last time
> > into my language" and "the current English text"
>
> svn diff ? svn browser ?

In order to do "svn diff" one needs to know the revision or the
timestamp of the "previously translated English text". Sure : the
translator can write down the revision number and use that
revision when doing 'svn diff' - but such a system would be
too manual and painful to seriously consider a solution.

Ok: I understand that there are no work resources for building some
web application for translating the website. Some time ago i've been
told that i'd have to rely on just CVS . I've accepted that and began to
translate the texts. And look what's the result: X months later when I had
the translation complete I found out that in fact the framework was not
ready for accepting new translations - and all the work was in vain
because when/if the everything will be ready i'll have to check and
translate every single page. Again.

Perhaps we could something like : every translated contains
a comment with the date+time+revision of the corresponding
English page ? at least this would make it possible to
manually manage the corresponding English revision for a given
translated page.

Cheers,
Adrian Maier