gandalf backed out a few landings to l10n-central for aurora for your locale, because those were strings that landed in en-US post the aurora cut for en-US. Now, on the next time you want to merge your work from central to aurora (around May 17), those backouts would just stick and remove the strings from your work again. The way to make hg likely do the right thing, or at least throw a merge conflict at you, is to land the "backout" changesets from aurora on l10n-central, back them out, and potentially merge. Double negation style, yeah, somewhat hard to wrap your head around. I can do that for you, but I want to make sure that you're good with it, and that we find the right time window so that your hg work doesn't clash. Sorry for the trouble, I'll do my best to make the next iteration suck less.
That's fine for me. Guillermo, any comments?
We have some problems being early-translator, right? Ricardo, we need to talk about the l10n procedure in our case. Meanwhile, please, make aurora to be clean for Firefox 5, we'll discuss about Firefox 6. Thanks!
Clarification: We need to clean up l10n-central to not run into issues on fx6. fx5 aka aurora right now is fine wrt compare-locales, i.e., that only needs QA and potentially fixes. The problem here is not that you're more on the early-bird side, the problem is that the planning of the creation of l10n/mozilla-aurora went with little to no planning on our side, and thus didn't happen in time. In the future, you could just work on l10n-central and merge to aurora every 6 weeks, and be mostly fine.
Created attachment 537668 [details] [diff] [review] diff between the current state of central and my working copy So I took a stab at this. Here's what my outgoing shows, changesets that would end up on l10n-central: searching for changes changeset: 848:e920eebb2b7c parent: 804:9f73ee69c8a0 user: Zbigniew Braniecki <email@example.com> date: Wed Apr 13 23:05:04 2011 -0700 summary: revert to aurora-merge state changeset: 849:b2739ab54754 user: Axel Hecht <firstname.lastname@example.org> date: Tue Jun 07 00:22:49 2011 +0200 summary: bug 650259, Backed out changeset e920eebb2b7c, aurora backouts shouldn't interfere with central. changeset: 850:56f24c2a5d43 parent: 849:b2739ab54754 parent: 847:1e60cc10a659 user: Axel Hecht <email@example.com> date: Tue Jun 07 00:23:41 2011 +0200 summary: merge backout of aurora backouts changeset: 851:35b9245bad43 parent: 848:e920eebb2b7c user: Guillermo Lopez <firstname.lastname@example.org> date: Tue May 10 14:01:14 2011 +0200 summary: Bug 655951. Transplanting bug 646082 from 2.0 to aurora. Thanks Pike for reporting changeset: 852:bfd38d378426 user: Ricardo Palomares <email@example.com> date: Sun May 15 23:20:23 2011 +0200 summary: Updating Thunderbird for 3.3 Aurora changeset: 853:a1ae5ca0d286 user: Ricardo Palomares <firstname.lastname@example.org> date: Sun May 15 23:40:56 2011 +0200 summary: Fixing bad output from development version of MT changeset: 854:85b4b9ff4ba6 user: Ricardo Palomares <email@example.com> date: Wed May 18 00:28:54 2011 +0200 summary: Fix typo in folderProps.dtd in Thunderbird changeset: 855:79c780fad90e user: Ricardo Palomares <firstname.lastname@example.org> date: Wed May 18 00:44:39 2011 +0200 summary: Fix for bad translation of 'archive' verb in Thunderbird changeset: 856:1d618e2ecb90 tag: tip parent: 850:56f24c2a5d43 parent: 855:79c780fad90e user: Axel Hecht <email@example.com> date: Tue Jun 07 00:40:08 2011 +0200 summary: merge aurora into central to prepare for the next cycle towards gecko 6 Attaching a diff between what's currently in central (1e60cc10a659) and my working copy. Willyaranda, is this good to land? Then I'd push it up to central and aurora.
Actually, the patch mainly touches mail files. The only browser (mobile) file edit looks good to me. Regarding mail changes, I've been reviewing files in aurora and they all have the entities/keys added by the attached patch, and also lacks the removed ones, so I'm all for pushing those changesets. And thanks a lot for your help, Axel.
I'm on this right now, and sadly, my first attempt was wrong, just pushing the second. I merged to tip of central instead of a state of the tree that was good for aurora. merge merge merge merge merge. Makes one-hell of a merry graph, http://hg.mozilla.org/l10n-central/es-ES/graph/859. Waiting for central to cycle, then I push some of that to aurora.
Ahh, finally. aurora and central look good, just two strings for mobile missing. No idea where they came in on central. https://l10n-stage-sj.mozilla.org/shipping/dashboard?locale=es-ES has all the tons of data. Marking FIXED.
Assignee: rpmdisguise-otros → l10n
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.