Gallery and Rosetta
Chris Kelly
ckdake at ckdake.com
Mon Dec 11 16:14:07 GMT 2006
On Dec 11, 2006, at 4:50 AM, Carlos Perelló Marín wrote:
>>> 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?
Ah. I had not thought of the time delay. I was envisioning the
commit to SVN occurring the moment the translator clicks submit
(which has definite timeout/resource issues).
As for conflict detection, notifying the last translator in Rosetta
for the specific conflict makes plenty of sense. You've probably
thought of a lot of the possibilities, but presenting both current
SVN and current Rosetta versions of a translation (when there are
conflicts) to anyone editing the translation would make sense, and I
might go as far as to prevent a translator from submitting a
translation with any "open" conflicts.
>> 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...
agreed.
> 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.
I've subscribed to the spec. I think that this could grow to be a
fairly important feature for encouraging external projects to use
Rosetta, and if translations are kept in mind as the regular SVN
conflict detection code and UI is developed, it shouldn't be much of
a burden to implement. Depending on Gallery's usage, we might send
some developer hours it's way :)
-Chris
--
Chris Kelly
ckdake at ckdake.com
http://ckdake.com/
More information about the launchpad-users
mailing list