Re: Multi-language to be or not to be - Mailing list pgsql-www

On 2/12/07, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Feb 12, 2007 at 11:37:16AM +0200, Adrian Maier wrote:
> > On 2/12/07, Magnus Hagander <magnus@hagander.net> wrote:
> > >On Mon, Feb 12, 2007 at 10:16:31AM +0200, Adrian Maier wrote:
> > >> To achieve  this I have the following idea :  every translated page
> > >> would contain a
> > >> comment like :   <!--  REVISION_NUMBER=xxxxxx -->   ,  where xxxxx is the
> > >> CVS revision of the corresponding English page.  It would be the
> > >> translator's job
> > >> to manually write the comment and modify it when he updates the
> > >translation
> > >> .
> > >> A script would later scan the files to get those revisions, then get
> > >> the latest revision
> > >> numbers from CVS and present them all as a table.
> > >
> > >Would it not be much easier to just check the *dates* on the files? Once
> > >a file is translated, you commit it. Then it can be considered
> > >up-to-date up until the point that the base file is newer than the
> > >translated one (when you change the base file).
> >
> > Revision number or commit date is almost the same thing.  When I am
> > looking at a certain translated file i want to know which is the date or
> > revision of the corresponding English file.  This piece of information makes
> > it possible to use cvs diff  for seeing the modifications that took place in
> > the meantime on the original file.
>
> Not in cvs. Each file has it's own revision number, whereas the date is
> ever-increasing. If you had repository revision numbers, this would be
> easier.

I'm not sure why per-file revision numbers are unsatisfactory.

The problem is that a "cvs diff" on the english pages doesn't answer the
question "i have this particular translated page.  Which is the version of the
corresponding english text ?  "

Giving an answer based on the commit dates is only an approximation,
because it takes some time until the translation is committed . It will
get painful if the english page is modified again before having the translation
comitted.

In particular, translating for the first time takes some time; the original
files are updated in the meantime.  It is getting painful when you realise that
you are translating a moving target and you don't have any real tools for
associating your translated file to the corresponding version of the original
file.   "cvs diff" is helpful but it's not enough


> And yes, we've been talking abuot moving the pgweb stuff into svn
> somewhere, but it's not done. And yes, if repo version numbers would
> help a lot here, it might be a tipping factor.
>
> What I'm against is having to store the revision number manually in the
> file, it seems like a very ugly and unmaintainable solution to me.

It is ugly indeed, but i'm not sure what else can be done without requiring
some work . A real solution would be having a table in the
database with the status of the translations and a web interface for uploading
the translations (so that the database would be updated ).
But I can't expect anyone to work on this, particularly since noone
ever provided
any translation so far.


> > >There's also the question of wether it's a good thing to have a say 15%
> > >translated site, vs a 0% translated one. If we have a 15% translation,
> > >that will give a very strange impression for people going there with a
> > >browser set for that language - some pages come up in their language,
> > >the majority comes up in a completely different language.
> >
> > I'm seeing this quite differently:    at first any translation is supposed
> > to
> > be almost 100% complete, but in time the contents will become old if
> > the english pages get updated but the translated pages aren't modified
> > accordingly.

> Well, once a page is out of date, I'd consider it "not translated". That
> said, there needs to be a very clear policy and a way to deal with
> it. Certain updates wouldn't need to invalidate the translatino (say a
> spelling or grammar fix), whereas certain others will need it to be
> completely invalidated right away (say information about a security
> issue, where you really don't want out-of-date information in different
> languages).

Yes, a policy will be needed.  But probably some translations need to
show up before discussing about the policy.

In 2-3 weeks from now i'll have some time to look at bringing up to date
the files.  But before spending time on them it would be nice to  know
whether the translation facility will be removed or not .. .


-- 
Adrian Maier