perldoc2-developers

[perldoc2-developers] datase vs. versioning

[Joergen W. L. <joe...@gm...>]

Hello everybody,

here is one question that needs to be resolved, before we start coding. 
Currently we are simply using SVN to store the documents and their 
translations.

As I wrote in the specification Vs. 0.1 a database could also be used 
for storage. The advantage appears to be that we do not have to add 
another layer of complexity to the application. Only one method is 
needed to access application data, documents and meta information.

Now - there appears to be one problem: What about versioning the 
translations? In one or the other situation there might be a need to do 
a "rollback" to a previous version of a translation.

Versioning systems like SVN are made exactly for this, but might not 
have the convenience of a database.

If we decide in favour of a database, we'd have to implement versioning 
by ourselves which might outweigh the complexity of another layer.

For the moment we could simply use the SVN repository on sourceforge as 
our central storage area which is fine as long as we do not need any 
extra features.

Please let me know your opinions and ideas!

Joergen

Re: [perldoc2-developers] datase vs. versioning

[Nicolas <nek...@gm...>]

Hi,

Just a note about the specifications.

Building a generic translation framework is something quite difficult, and
other projects are already working on it: Rosetta, Pootle, Transdict, etc.

IIRC, the specifications for Rosetta are publicly available (but the
implementation is not free). The Pootle's specifications are publicly
available
(http://translate.sourceforge.net/wiki/wordforge/functional_specificaions)

They may be worth reading if you want to build a translation
infrastructure .

Best Reagrds,
-- 
Nekral

Re: [perldoc2-developers] datase vs. versioning

[Joergen W. L. <joe...@gm...>]

Hi Nekral,

now *this* is important! Maybe we don't have to build from scratch at 
all. Especially TransDict looks interesting since it's written in Perl. 
I will have a look at it tonight.

Joergen

Nicolas François schrieb:
> Hi,
> 
> Just a note about the specifications.
> 
> Building a generic translation framework is something quite difficult, and
> other projects are already working on it: Rosetta, Pootle, Transdict, etc.
> 
> IIRC, the specifications for Rosetta are publicly available (but the
> implementation is not free). The Pootle's specifications are publicly
> available
> (http://translate.sourceforge.net/wiki/wordforge/functional_specificaions)
> 
> They may be worth reading if you want to build a translation
> infrastructure .
> 
> Best Reagrds,

Re: [perldoc2-developers] datase vs. versioning

[Joergen W. L. <joe...@gm...>]

Hi,

Sorry for being late with my reply. I'm working on the german 
translation of the "CSS Cookbook" for O'Reilly. That eats a lot of my time.

The Actual Subject

Specifically there is one point I did not think of:

There should be versioning/a backup facility for the translations. Which 
more or less means a combination of a database-based storage for recent 
versions and a SVN repository (which we already have!) as a 
"backend-backend". (...unless we wanted to re-implement versioning 
within the DB.)

Generic/Specific Framework

The focus should stay on the translation of the perl documentation for 5 
and 6. If there is a chance to build it so it allows future extensions 
for other languages - fine. If not we should not worry too much.

Pootle/Transdict/Rosetta

I had a closer look at Pootle and Transdict. Especially Transdict looked 
interesting at first glance since it's written in Perl. I thought it 
might serve as a starting point but the coding appears to be dating back 
to Perl 4 with hardly any documentation/comments in the code. The 
application is based on .cgi files that have to be in the document 
root... Nah. Rather not.

Pootle appeared to promising but didn't want to install on my 
Debian/Sarge machine without a kernel change or a lot of manual 
instllation. Or does it make more sense to just use that? I'm still not 
100% sure.

Also, since it's written Python, changes, alterations, extensions would 
not be as easy for us as with our "native" language, Perl. Apart from 
that, if we used Pootle, we would loose the "promotion" effect.

But I learned a few important lessons from their approach:

- document as much as you can
- don't announce or link to features that are not there, yet

Their specification is very well organized and will definitely be a good 
source of inspiration for the perldoc 2.0 spec 0.3.

So much for now,
will be back, soon with more info,

Joergen


Nicolas François schrieb:
> Hi,
> 
> Just a note about the specifications.
> 
> Building a generic translation framework is something quite
> difficult, and other projects are already working on it: Rosetta,
> Pootle, Transdict, etc.
> 
> IIRC, the specifications for Rosetta are publicly available (but the 
> implementation is not free). The Pootle's specifications are publicly
>  available 
> (http://translate.sourceforge.net/wiki/wordforge/functional_specificaions)
> 
> 
> They may be worth reading if you want to build a translation 
> infrastructure .
> 
> Best Reagrds,

Re: [perldoc2-developers] datase vs. versioning

[Nicolas <nek...@gm...>]

On Tue, Dec 12, 2006 at 10:59:19AM +0100, Robert 'phaylon' Sedlacek wrote:
> Hi Joergen,
> 
> Joergen W. Lang wrote:
> 
> > Pootle appeared to promising but didn't want to install on my 
> > Debian/Sarge machine without a kernel change or a lot of manual 
> > instllation. Or does it make more sense to just use that? I'm still not 
> > 100% sure.
> 
> What did it need _that_ for?

It is "just" a dependency issue.
The python modules packaging changed between Sarge and the current
Debian release, so pootle requires a new python infrastructure, which
probably requires the new libc, etc.

Pootle can be installed on its own (it requires jToolkit, which requires
kid and elementtree).

Regarding the infrastructure, except if we want to have mass translation
from a web interface, the subversion interface + commit logs for reviews
+ export on a web interface is perfect for me.

Regard,
-- 
Nekral

[perldoc2-developers] Pootle, was datase vs. versioning

[Joergen W. L. <joe...@gm...>]

Nicolas François schrieb:
> On Tue, Dec 12, 2006 at 10:59:19AM +0100, Robert 'phaylon' Sedlacek wrote:
>> Hi Joergen,
>>
>> Joergen W. Lang wrote:
>>
>>> Pootle appeared to promising but didn't want to install on my 
>>> Debian/Sarge machine without a kernel change or a lot of manual 
>>> instllation. Or does it make more sense to just use that? I'm still not 
>>> 100% sure.
>> What did it need _that_ for?
> 
> It is "just" a dependency issue.

Exactly.

> The python modules packaging changed between Sarge and the current
> Debian release, so pootle requires a new python infrastructure, which
> probably requires the new libc, etc.

Also, Python 2.5 did not like to install from source. Since the Debian 
machine is my production server I do not like to mess around with it too 
much. I can try to run it on my local machine (Mac OS X) but that would 
only give us *very* limited access since I share the DSL line with three 
other parties.

I will meet with a Python expert tonight. Maybe he can shed some light 
on the situation.

So, if we wanted to use Pootle as the platform we are left with three 
options:

1. Get perldoc 2.0 onto the "official" wordforge/Pootle server
2. Find some other webspace provider with the neccessary infrastructure
3. Build our own from scratch

(your ideas here)

> Pootle can be installed on its own (it requires jToolkit, which requires
> kid and elementtree).

Downloaded these. Will give it another try later today.

> Regarding the infrastructure, except if we want to have mass translation
>>from a web interface, the subversion interface + commit logs for reviews
> + export on a web interface is perfect for me.

Hmmm, maybe a compromise will suffice. Use Pootle as long as we have to 
and later migrate to our own platform.

I will contact the Pootles by mail and see what they have to say about it.

Greetings,

Joergen

Re: [perldoc2-developers] datase vs. versioning

[Robert 'p. S. <rs...@47...>]

Hi Joergen,

Joergen W. Lang wrote:

> Specifically there is one point I did not think of:
> 
> There should be versioning/a backup facility for the translations. Which 
> more or less means a combination of a database-based storage for recent 
> versions and a SVN repository (which we already have!) as a 
> "backend-backend". (...unless we wanted to re-implement versioning 
> within the DB.)

Well, if we're going to keep the structure and contents in the database,
versioning isn't _that_ much to add. It would also keep everything in
one place and backups should include the versioning IMO.

> Generic/Specific Framework
> 
> The focus should stay on the translation of the perl documentation for 5 
> and 6. If there is a chance to build it so it allows future extensions 
> for other languages - fine. If not we should not worry too much.

I don't see anything that would hinder other uses, except we start
hardcoding stuff.

> Pootle appeared to promising but didn't want to install on my 
> Debian/Sarge machine without a kernel change or a lot of manual 
> instllation. Or does it make more sense to just use that? I'm still not 
> 100% sure.

What did it need _that_ for?

gr.,
Robert

-- 
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs...@47... ', Web => ' http://474.at ' }