Re: PostgreSQL website translations - Mailing list pgsql-www

On Mon, Mar 24, 2008 at 12:26 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Adrian Maier a écrit :
>  > On Mon, Mar 10, 2008 at 1:13 PM, Guillaume Lelarge
>  > <guillaume@lelarge.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