On December 14, 2010 03:06:17 am davidefa wrote:
> It seems that the last changes to the 2010.4 and default branches ( a
> few hours ago ) removed the changes to the italian translation already
> done in 2010.4beta2.
> The file it.po in 2010.4 and default branches is the same of the
> 2010.4beta1

can you be more precise to help identify the problem? what strings have 
regressed exactly?

Looking at the it.po changelogs for default [0] and 2010.4 [1] the last change 
was me two weeks ago.

I suspect I broke _all_ the translations because default and 2010.4 diverged 
shortly after 2010.4 was branched.  See below for detailed hypothesis and 
current, unfinished thinking about the solution.

The problem is compounded by the fact that I don't speak all of the languages 
and it is thus difficult to identify what is a regression for me.

So far the only two signs that things went wrong came from the Czech 
translation (my changes to it broke the build yesterday and I reverted it 
since) and from your feedback.

I don't have a solution yet and won't have time to work on it today as I am 
leaving soon for a full day of on-site interviews.  If somebody has the time 
to continue the analysis below, I'd be grateful.  Else I'll try to do it 
before releasing RC1.


HYPOTHESIS

My current hypothesis is that this happened when extracting the strings anew 
after the divergence (and we did it a couple of time).  I am still trying to 
figure out what went wrong - in the past such divergence was not a problem.  I 
suspect that this is because in the past new strings were added to default 
only while this time I added strings to 2010.4.  Need to be verified.


CONSEQUENCES

* The process of keeping in sync release and default needs refinement.
* The edits to the translation files of the past few weeks needs to be saved.


PROCESS IMPROVEMENTS

The process that needs refinement is the one of keeping in sync release and 
default [2].  Simply replicating the changes from default to release (or the 
other way around) does not seem to work when default and release are apart.

Probably the new process will add some sort of msgmerge as described in [3].


SAVING THE TRANSLATION EDITS

Other than redesigning the sync process, there is the mess to sort out.  Most 
(but not all) translation edits happened in default.  My current, incomplete 
thinking, is the following:
- collect all the individual diffs to language files excluding the 
transplanted diffs
- run the extract-strings process on default and on 2010.4 separately (no 
transplantation of the changeset)
- try to apply the diffs, separately on each branch
- in the future, always msgmerge when there is a change in a language file 
(and maybe ask that no translation work is done directly in the repo?)


(TEMPORARILY) CONCLUDING THOUGHTS

Sorry if I leave this in the middle like this, I have no time to take care of 
this now.  If nobody picks this up, I'll do so before releasing RC1.  RC1 was 
planned for Friday 17 Dec.  This date may slip.

Yuv


[0] 
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/log/default/src/translations/it.po
[1] 
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/log/2010.4/src/translations/it.po
[2] 
http://wiki.panotools.org/Development_of_Open_Source_tools#Keeping_the_Release_Branch_in_Sync_with_Default
[3] http://wiki.panotools.org/Hugin_translation_guide#Developer_info

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to