Localizers who are working on l10n-central are responsible for getting their work onto the Aurora repository.
Here some tips and tricks for syncing up both l10n-central and releases/l10n/mozilla-aurora at the same time en-US goes from central to aurora.
You want to have a repo from which you can uplift to aurora shortly after the migration. The Releases page on wikimo has the upcoming dates. You should be good doing it the day after.
You don't need to work on making the synchronization happen in either of your copies of the aurora or central repositories, but you can create a third one for this work. We even suggest that you do. That makes it easier to throw away attempts that didn't work.
So, here are the mercurial steps to reproduce.
Prerequisites:
- merge tool. You really want a merge tool for this. I use kdiff3; you may choose your own based on what you read at https://mercurial.selenic.com/wiki/MergeProgram
- a clone of your central repo. Let's pretend it's at l10n-central/ab-CD.
- a clone of your aurora repo. Let's pretend it's at releases/l10n-mozilla-aurora/ab-CD
Here's how we do it:
# set up a new local clone of your central repo
hg clone l10n-central/ab-CD workrepo
cd workrepo
# pull in the changesets you have on aurora
hg pull -r default ../releases/l10n/mozilla-aurora/ab-CD
Now, there are two routes forward:
1) things are pretty silent.
Good luck, you're basically done. All you need to do is to push from your l10n-central clone to your aurora repo.
2) new heads, you need to merge. this looks something like
searching for changes
adding changesets
adding manifests
adding file changes
added 22 changesets with 23 changes to 46 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
OK, let's make sure we're not talking relbranches:
hg heads --template '{node} {branches}\n'
This is printing something like
5131e147fa50c28ec858c7d9fd1ba201ea2a433b
4da525ed77699794c56081791bd46cc85983f6f8
9bc7e6c58fc091c8cd0e8d9e1dbc7e6f592772a7 GECKO20b12_2011022218_RELBRANCH
230e99fada602842d9630e673077ef9f1ab34247 GECKO20b12pre_20110216_RELBRANCH
41a4357884d7bcc50e69c71014124d3af2482afe COMM20b11_20110203_RELBRANCH
2ec6ad14e7168ebeb999b1e8ae10632ae4c9df23 GECKO20b11_2011020209_RELBRANCH
d68e647ac3c0fee709c13abb0f03fac24a1a5d29 GECKO20b11pre_20110126_RELBRANCH
7ff37dc6837669363a51ad3fd2874ac845d312d5 GECKO20b10_2011012115_RELBRANCH
6c31fe9bc065a86aea2223ba48698f18ae7563ad GECKO20b9_2011011018_RELBRANCH
Here you can see that there are two changesets without a branch. So yes, you need to merge those two.
hg merge
If this just passes, you want to commit, and you probably want to use a commit message like "merging central and aurora". You can safely push this to l10n-central already, in particular if you don't plan to do further updates on aurora. You don't want to push this to aurora before there's been the notification that the status of aurora has been lifted up to beta.
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, and you really want to make sure that your aurora clone doesn't have quality issues. In particular, did you land all the fixes for your work on both central and aurora? Because mercurial suggests that you didn't. Look at the merge conflicts, and figure out if there's stuff that you still want to land on aurora. If so, you want to fix those issues on aurora alone, verify them there, and then go back to this page. One of the reasons why we suggested that you do the merging in a separate tree is just this. You can just throw your merge candidate away as long as you find fixes that you've forgotten on either aurora or beta, and address those in their own repos first. Push them to hg.mozilla.org there, verify the builds, and then try to merge l10n-central and aurora again.
There is one scenario where you don't want to have the conflicts resolved outside of the actual merge: en-US on central changed, in a way that doesn't make sense on aurora. Say, en-US removed a string for the release+2, and you fixed a typo in the string that still exists in release+1. So you fixed the string on aurora, and you removed the broken string on central. That's gonna conflict, and you need to resolve that with your merge tool so that the resulting localized file doesn't have the string any more.
Now, if you read this far, you may be overwhelmed, and that's OK. Ask for help. The folks on #l10n won't be able to make language decisions for you, but there will be folks around to explain why you're seeing a merge conflict, and if you're looking for a fix on one branch, on the other, or on both.
At this point, your resulting workrepo has no more conflicts, and thus it's time to publish it again. In the workrepo directory, do
#verify that we didn't forget changesets
hg inc ../l10n-central/ab-CD
comparing with ../l10n-central/ab-CD
searching for changes
no changes found
hg inc -r default ../releases/l10n/mozilla-aurora/ab-CD
comparing with ../releases/l10n/mozilla-aurora/ab-CD
searching for changes
no changes found
# push to central
hg push ../l10n-central/ab-CD
# push to aurora
hg push ../releases/l10n/mozilla-aurora/ab-CD
# push l10n-central upstream
cd ../l10n-central/ab-CD
hg push
# push aurora upstream
cd ../../releases/l10n/mozilla-aurora/ab-CD
hg push
Keep in mind that at this point, aurora and beta correspond to different states of l10n, and thus you don't want to push the aurora state to beta.