940926 - [es-ES] Merge mozilla-aurora/es-ES to l10n-central/es-ES

Status: RESOLVED FIXED

(Mozilla Localizations :: es-ES / Spanish, defect)

Description

[Francesco Lodolo [:flod]]

As part of bug 939834 I've just landed some productization changes to mozilla-aurora and wanted to merge Aurora down to Central.

I tried to merge down to central but it's a mess, changed strings all over the place. 

I temporarily transplanted the changeset to be sure it's there
http://hg.mozilla.org/l10n-central/es-ES/rev/ce2aeae934c6

It would nice to merge Aurora to Central to start clean, and then follow the proper procedures to move strings between repositories.

Comment 1

[RickieES aka Ricardo Palomares]

Honestly, Guillermo and I tried to follow the Uplifiting localization from central to aurora channel back when the fast development cycle entered into scene (so there couldn't be many deviations among both channels), and we encountered so many problems and found the process to be so cumbersome and little to no rewarding vs. just migrating the data in MozillaTranslator and simply dumping the already translated strings, that we resigned. I read the document again some time later and I think I even tried again, with no change in my opinion. What's the real benefit of transplanting changesets when the sign-offs always start from Aurora, never in Central, and the transplanted files do not involve logic that can be lost or difficult to track (as it is the case with code files)?

I'm happy to manually porting the changes, though.

Comment 2

[Francesco Lodolo [:flod]]

Pros: consistent history, you're sure you can't forget changes in a place or another because merge will tell you. 

Our team has been following this procedure for almost a couple of years and we never encountered a single problem.

1) Two of us work on l10n-central, another one works on mozilla-aurora (Thunderbird).

2) When you need to do changes on Aurora, you do this (and that's the only important part to remember)

a) Do your changes and commit to mozilla-aurora
b) Import in l10n-central the new changes
> hg pull -r default ../mozilla-aurora
> hg merge

Check if everything looks good and commit this merge
> hg commit -m "Merge Aurora to Central"

Need to change something on Beta? Fix it, merge down to Aurora and then again to Central.

3) On merge day, you follow these instructions to merge Aurora and Central
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Uplifting?redirectlocale=en-US&redirectslug=Uplifting_a_Localization_from_central_to_aurora

Merge day for me is just copying and pasting 3 lines in a terminal :-)

If you're sure that all changes in Aurora are already included in l10n-central, I can do a merge and, in case of conflicts, keep files on l10n-central as good. Just let me know if this works for you.

Comment 3

[RickieES aka Ricardo Palomares]

(In reply to Francesco Lodolo [:flod] from comment #2)
> 3) On merge day, you follow these instructions to merge Aurora and Central
> https://developer.mozilla.org/en-US/docs/Mozilla/Localization/
> Uplifting?redirectlocale=en-
> US&redirectslug=Uplifting_a_Localization_from_central_to_aurora
> 
> Merge day for me is just copying and pasting 3 lines in a terminal :-)


Yeah, the problem for us is that it never was just copying and pasting those three lines. The first we tried we already found a lot of differences.

I've tried again now. The first thing that has stroked me is that Meld (the equivalent for KDiff3 in Gnome) does not really explains what are the two temp versions (middle and right windows, being workrepo the left one). I presume the right one is Aurora and temp should be the working dir of workrepo, so it should always match workrepo, but the fact is that the version in the middle window looked most of the time as outdated, being the right one closer to workrepo (but not completely equal). Looking at the files through a regular file explorer instead of Meld, it really looks like that disposition is workrepo (so, l10n-central), somehow outdated version, aurora. That's what probably puzzled us and made us discard this method and migrate the channels through MozillaTranslator (which is anyway faster).

Anyway, I'm going to try to repeat the uplifting process several times to clean the differences and report back. This could last until the weekend, so please be patient. :-)

Comment 4

[Francesco Lodolo [:flod]]

> The first we tried we already found a lot of differences.
Once it's done the first time, it shouldn't happen.

(In reply to Ricardo Palomares from comment #3)
> Anyway, I'm going to try to repeat the uplifting process several times to
> clean the differences and report back. This could last until the weekend, so
> please be patient. :-)

Sure, it's not urgent ;-)

You could also try this. Create a clean clone of l10n-central, then.
hg pull -r default ../mozilla-aurora
hg merge --tool internal:local

This tells merge to use always the local file in case of merge conflicts
http://mercurial.selenic.com/wiki/TipsAndTricks#Keep_.22My.22_or_.22Their.22_files_when_doing_a_merge

This is obviously good for this one time. Starting from this point all merges should be easier to do (ideally you should never have conflicts).

Comment 5

[Francesco Lodolo [:flod]]

I tried with hg merge --tool internal:local and this is what I get.

warning: cannot merge flags for b2g/chrome/overrides/appstrings.properties
warning: cannot merge flags for browser/chrome/browser/devtools/debugger.dtd
warning: cannot merge flags for browser/chrome/browser/devtools/debugger.properties
warning: cannot merge flags for browser/chrome/browser/devtools/gcli.properties
warning: cannot merge flags for browser/chrome/browser/devtools/gclicommands.properties
warning: cannot merge flags for browser/chrome/browser/devtools/inspector.properties
warning: cannot merge flags for browser/chrome/browser/devtools/layoutview.dtd
warning: cannot merge flags for browser/chrome/browser/devtools/scratchpad.dtd
warning: cannot merge flags for browser/chrome/browser/devtools/scratchpad.properties
warning: cannot merge flags for browser/chrome/browser/devtools/sourceeditor.dtd
warning: cannot merge flags for browser/chrome/browser/devtools/styleinspector.dtd
warning: cannot merge flags for browser/chrome/browser/devtools/styleinspector.properties
warning: cannot merge flags for browser/chrome/browser/devtools/webconsole.properties
warning: cannot merge flags for browser/chrome/browser/syncProgress.dtd
warning: cannot merge flags for browser/searchplugins/metrolist.txt
warning: cannot merge flags for mobile/android/base/android_strings.dtd
warning: cannot merge flags for mobile/android/base/sync_strings.dtd
warning: cannot merge flags for mobile/android/chrome/aboutCertError.dtd
warning: cannot merge flags for mobile/android/chrome/browser.properties
warning: cannot merge flags for mobile/android/chrome/checkbox.dtd
warning: cannot merge flags for mobile/android/chrome/config.dtd
warning: cannot merge flags for mobile/android/chrome/feedback.dtd
warning: cannot merge flags for mobile/android/chrome/localepicker.properties
warning: cannot merge flags for mobile/android/chrome/notification.dtd
warning: cannot merge flags for mobile/android/chrome/phishing.dtd
warning: cannot merge flags for mobile/android/chrome/prompt.dtd
warning: cannot merge flags for mobile/android/chrome/sync.dtd
warning: cannot merge flags for mobile/android/chrome/sync.properties
warning: cannot merge flags for mobile/overrides/appstrings.properties
warning: cannot merge flags for mobile/overrides/netError.dtd
warning: cannot merge flags for mobile/overrides/passwordmgr.properties
warning: cannot merge flags for webapprt/webapprt/webapp.dtd
warning: cannot merge flags for webapprt/webapprt/webapp.properties
299 files updated, 37 files merged, 0 files removed, 0 files unresolved

So I checked the last file and they actually have different permissions.

-rwxr-xr-x  l10n-central/webapprt/webapprt/webapp.properties
-rw-r--r--  mozilla-aurora/webapprt/webapprt/webapp.properties

This is the resulting commit on a test repository
https://bitbucket.org/flod/temp_eses/commits/4606f7f502a8363142fb302137b35ccbe43650d6

The only real difference I can see is the license header in mobile/searchplugins/11870.xml

Comment 6

[RickieES aka Ricardo Palomares]

Just a short note to say that I've suffered a hard disk failure. I'm still getting up to date with everything, including Mozilla. I wonder if, given that we're quickly approaching to cycle shift, it could be better to wait until then to do the merge. :-?

Comment 7

[Francesco Lodolo [:flod]]

It's not urgent at this point, so don't worry ;-)

Right now all productization changes are in place, both on Aurora and Central, thanks to transplant. 

In the next cycle I'll probably need to land more changes and I'll have the same problem, so it would be nice to have merged repositories at some point.

Comment 8

[RickieES aka Ricardo Palomares]

(In reply to Francesco Lodolo [:flod] from comment #7)
> In the next cycle I'll probably need to land more changes and I'll have the
> same problem, so it would be nice to have merged repositories at some point.


OK, so I have just pushed merge commits for Central and Aurora following the Uplifting localization... document, but I'm pretty sure something is not right. For instance, styleinspector.properties is now in es-ES central and I don't have it in my MozillaTranslator Firefox product nor in comm-central/mozilla/browser/locales/en-US/chrome/browser/devtools.

The main divergence between the MDN doc instructions and my experience is when it says:

"If hg merge starts asking you questions, you have a merge conflict. That indicates that the same string has different translations on l10n-central and aurora"

but the fact is that I got conflicts just because there are new strings in central not present in Aurora (that's why we are merging in the first place, don't we?).

I'll check L10n dashboard tomorrow to see how it looks.

Comment 9

[Francesco Lodolo [:flod]]

The problem is the starting point, you had repositories with several conflicts. From now on you shouldn't have this kind of problems.

(In reply to Ricardo Palomares from comment #8)
> For instance, styleinspector.properties is now in es-ES central and I
> don't have it in my MozillaTranslator Firefox product nor in
> comm-central/mozilla/browser/locales/en-US/chrome/browser/devtools.

That's because it was moved from browser/devtools to toolkit in this cycle
http://hg.mozilla.org/l10n-central/it/rev/1442d386949d

So you should just remove it again on mozilla-central.

Comment 10

[Francesco Lodolo [:flod]]

Ricardo, I believe this can be closed since you already did the merge.

Comment 11

[RickieES aka Ricardo Palomares]

(In reply to Francesco Lodolo [:flod] from comment #10)
> Ricardo, I believe this can be closed since you already did the merge.

Yes, I agree, closing, thanks for the reminder.