Gallery and Rosetta

[Carlos Perelló Marín]

El dom, 03-12-2006 a las 19:25 -0500, Chris Kelly escribió:
> On Nov 29, 2006, at 3:40 AM, Carlos Perelló Marín wrote:
> > El jue, 02-11-2006 a las 21:30 -0500, Chris Kelly escribió:
> >> On Oct 27, 2006, at 12:37 PM, Carlos Perelló Marín wrote:
> >>
> >> Here's how the perfect system would work from my point of view:
> >>
> >> 1.  We sign up Gallery with Rosetta and give it svn access to our
> >> repository hosted by sourceforge (Rosetta would have a sf.net
> >> username that we could grant write access to our project and notify
> >> Rosetta once this was done)
> >
> > I guess this would be to do commits from Rosetta...
> 
> Yes.

Ok

> 
> >> 2. Rosetta would track our source code via svn, regular/nightly/etc
> >> updates would be good, perhaps following a tracking system such as
> >> the -checkins mailing list or CIA would be nice.
> >
> > This is already done by our svn->bzr process daily.
> 
> As I found out trying to get SVN synching from Gallery working.  Cool.
> 
> >> 3. Whenever a translator started work in Rosetta on Gallery, Rosetta
> >> would ensure that the file they were working on was up to date.
> >
> > Once we link Rosetta with bzr, we should be up to date (or at most,  
> > miss
> > only changes since last sync.
> 
> Gotcha.
> 
> >> 4. Whenever a translator finished their work and saved it, Rosetta
> >> would make a commit directly to Gallery svn of only the updated
> >> language files and would include a good log message (this would
> >> require running a Makefile with our current setup)
> >
> > I'm not completely sure whether the automatic imports should be  
> > done...
> > but it's doable. But...
> >
> >> This would allow minimal management overhead on our end, the
> >> flexibility of translators to use svn on their own or Rosetta to do
> >> translation, and the ability for changes to show up immediately.
> >
> > There is a race condition here:
> >
> > 1. We check that we are up to date
> > 2. Someone starts translating in Ubuntu.
> > 3. You or any other translator updates the same .po file in SVN
> > 4. We do the commit to SVN.
> > 5. Conflicts!!
> >
> > Most of the time, it will work, but that race condition is there, how
> > would you handle that?
> 
> The most reasonable way to do this would probably be an interface in  
> Rosetta for managing merge conflicts. If a commit fails with the  
> local copy being out of date, Rosetta would do a svn up, merge  
> changes that are the same, and present a UI for manual selection of  
> which strings to use.

I have a feature to detect conflicts already implemented that is being
reviewed, it's not designed for this kind of conflicts, but I guess we
could reuse the concepts there to implement such feature. The idea would
be to notify someone (I guess last translator in Rosetta) that upstream
has translations that conflict with his work and that it blocks that we
'commit' the file directly to upstream.

How does it sound?

> 
> I don't see this being specifically a problem for Gallery because we  
> typically only have one translator working on a language and they  
> would choose their input method (Rosetta or committing the po by  
> hand), but I can see how this could crop up close to release time  
> with multiple translators working on the same language.

sure, but that's something that could happen, and what should we do if
we don't know how to deal with conflicts and we find one? So if we
implement the commit feature, we should also implement the conflict
resolution...

I cannot give you a date for this feature being implemented or even if
it will be implemented. I think it's interesting and I will raise it as
a possible new feature to implement.

I added a new spec for this feature at:
https://blueprints.launchpad.net/products/rosetta/+spec/upstream-translation-commit

If you subscribe to it, you will know its status and whether it's
approved or rejected.

> 
> >> Does that make sense and sound possible somewhere far down the line?
> >> (Or are you primarily concerned with working with projects hosted on
> >> Bazaar?)
> >
> > At the moment, our primary target is to work with Bazaar trees.  
> > Anyway,
> > there is a work in progress plugin for Bazaar that will allow us to do
> > commits to SVN repositories from Bazaar branches (I'm not completely
> > convinced about this). The read of CVS/SVN repositories is already
> > solved with a mirroring tool that converts them in Bazaar branches.
> 
> Understood and as expected.

Cool.

Cheers.

> 
> Thanks!
> 
> -Chris
> 
> --
> Chris Kelly
> ckdake at ckdake.com
> http://ckdake.com/
> 
-- 
Carlos Perelló Marín
Ubuntu => http://www.ubuntu.com
mailto:carlos.perello at canonical.com
http://carlos.pemas.net
Alicante - Spain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : https://lists.ubuntu.com/archives/launchpad-users/attachments/20061211/56d4e7da/attachment.pgp