[ANNOUNCE] mozilla-central to aurora uplift coming this Tuesday, action required for l10n-central teams
Axel Hecht
we'll be lifting the content on mozilla-central up to mozilla-aurora,
that is, we'll get a new strings on aurora. This is independent of what
we're currently working on on beta. But starting tomorrow, the
mozilla-aurora and the mozilla-beta repository will no longer match
string wise.
For those localization teams that have been ignoring l10n-central,
that'll mean that you'll want to go to your mozilla-aurora clone, and
hg pull -u
and you should be fine.
For those localization teams that have been working on l10n-central in
the past few weeks, there's an action coming up for you.
I've written up some documentation on what exactly on
https://developer.mozilla.org/en/Uplifting_a_Localization_from_central_to_aurora.
It's rather detailed on hg commands and what output to expect etc. The
short story is:
You want to merge your aurora state and your central state. Merge
conflicts may arise, which are an indication that some fix is missing on
either side. You'll need to dig in and figure out what the right thing
to do is. We'll be glad to help out on irc on the mechanics.
Axel
Mad_Maks
> Hi,
>
> we'll be lifting the content on mozilla-central up to mozilla-aurora,
> that is, we'll get a new strings on aurora. This is independent of what
> we're currently working on on beta. But starting tomorrow, the
> mozilla-aurora and the mozilla-beta repository will no longer match
> string wise.
>
> For those localization teams that have been ignoring l10n-central,
> that'll mean that you'll want to go to your mozilla-aurora clone, and
>
> hg pull -u
>
> and you should be fine.
>
> For those localization teams that have been working on l10n-central in
> the past few weeks, there's an action coming up for you.
>
> It's rather detailed on hg commands and what output to expect etc. The
> short story is:
>
> You want to merge your aurora state and your central state. Merge
> conflicts may arise, which are an indication that some fix is missing on
> either side. You'll need to dig in and figure out what the right thing
> to do is. We'll be glad to help out on irc on the mechanics.
>
> Axel
I have imported all the changes in aurora at the same time in central
and worked the last days on central. Do you guys lifting the content
to aurora or do i do that (and how is the best way to do that)?
greetings
Mad Maks
Axel Hecht
Yes, you're on the hook for pushing your merge up to hg for both central
and aurora.
I've added more content beneath the merge text about how to get the
content from your workrepo to your local central and aurora clones, and
from there up onto hg.m.o.
Axel
flod
> I've written up some documentation on what exactly on
> https://developer.mozilla.org/en/Uplifting_a_Localization_from_central_to_aurora.
> It's rather detailed on hg commands and what output to expect etc. The
> short story is:
Not sure why, but this code doesn't work on my Windows machine
(TortoiseHg 2.0.4 with Mercurial 1.8.3)
> |hg heads --template '{node} {branches}\n'|
Looks like it searches for a revision name after a space, the error
displayed is
> abort: unknown revision '{branches}'
Removing spaces is enough
> |hg heads --template '{node}___{branches}\n'|
Francesco
Axel Hecht
Which shell are you using? cmd.exe?
If so, maybe you can get it to work with `\ `, if the '' quotes don't
escape stuff there?
Axel
flod
> If so, maybe you can get it to work with `\ `, if the '' quotes don't
> escape stuff there?
didn't think about the quotes).
Francesco
flod
l10n-central).
This is needed only if there are QA issues between mozilla-aurora and
l10n-central, isn't it? Anyway, when I try to "hg push ../l10n-central/it" I
get this scary message.
abort: push creates new remote branches: GECKO50b1_20110512_RELBRANCH!
> (use 'hg push --new-branch' to create new remote branches)
>
Unless I did some mistakes in the middle[1], this should happen to other
locales.
Francesco
[1] for what I can understand, everything seems fine on mozilla-aurora
http://hg.mozilla.org/releases/l10n/mozilla-aurora/it/graph
Axel Hecht
Right, I need to tweak that.
You get this because there's a relbranch on aurora that's not on
l10n-central. I don't really know why some have that relbranch, or if
everybody does.
You should be able to just only push default to central.
I've updated the doc to just pull -r default from aurora, then you'll
not even run into this issue.
Axel
Ricardo Palomares Martínez
> For those localization teams that have been working on l10n-central in
> the past few weeks, there's an action coming up for you.
>
> You want to merge your aurora state and your central state. Merge
> conflicts may arise, which are an indication that some fix is missing
> on either side. You'll need to dig in and figure out what the right
> thing to do is. We'll be glad to help out on irc on the mechanics.
Axel, as MozillaTranslator saves internally both en-US and ab-CD
strings, it can be used to switch the en-US strings source from
central to aurora, "update", thus removing obsolete strings and
signaling any modified or "new" string in en-US, so ab-CD can be
adjusted accordingly. After that, exporting the localization would be
useful to provide a single changeset to turn green the dashboard.
Guillermo has tried it with browser (desktop and mobile) modules and
it seems to put a significant lesser workload than dealing with
merging repos. My question is: is OK for l10n-drivers if we follow
this path, providing an independent changeset, instead of merging and
fixing?
If this fits you, I can write a how-to for people using MozillaTranslator.
TIA
smo
who's Mozilla Translator (g)?
I am curious: the "saves internally both en-US and ab-CD" rings a bell
for me.
TiA
smo
Axel Hecht
I'd rather keep the mercurial trees related as the content is. There
might be ways to merge, drop the MT export, and then commit the merge.
Somewhat similar to a no-op merge as in
http://mercurial.selenic.com/wiki/PruningDeadBranches#No-Op_Merges, just
that you don't revert.
Also, there's going to be a question on how many localizations really
want to follow central on a day-to-day basis, and how many are just
going to pick things up on aurora when the next cycle starts.
Axel
Ricardo Palomares Martínez
>
> who's Mozilla Translator (g)?
>
> I am curious: the "saves internally both en-US and ab-CD" rings a bell
> for me.
MozillaTranslator (MT for short, not really related to Machine
Translation abbreviation) is probably the oldest L10n tool (besides
UTF-8 text editors) used to localize Mozilla products. It appeared
about 2001 and was written by Henrik Lynggaard, a Danish Mozilla
localizer. It is a desktop application written in Java and currently
maintained by me (when time allows).
MT was designed when L10n didn't involve dealing with repositories,
but with simple JAR and XPI files, so it basically opened the
en-US.jar file (and other en-*.jar files), read it, created an
in-memory tree of the JAR content and allowed translating them. On MT
exit, or by choosing File -> Save Glossary, all current state (en-US
and ab-CD strings) was saved in a Properties file utterly compressed
to a file named Glossary.zip (again, not really a glossary). The
Properties file works as a "poor man's" database.
On later MT invocations, you was able to "update" the current state,
so MT re-read the JAR files (which you might have replaced with newer
versions) and compared its contents with the current state, deleting
removed strings, and presenting a list of new and updated strings.
That's why MT didn't need entity/key renaming when a en-US string was
changed.
All of the above (for good and bad) is still true as of today, except
that since MT 5.02 (IIRC) JAR files can be replaced by directory
subtrees in your hard disk.
MT has a page in wmo:
https://wiki.mozilla.org/Mozillatranslator
HTH
Ricardo Palomares Martínez
> I'd rather keep the mercurial trees related as the content is. There
> might be ways to merge, drop the MT export, and then commit the merge.
> Somewhat similar to a no-op merge as in
> http://mercurial.selenic.com/wiki/PruningDeadBranches#No-Op_Merges,
> just that you don't revert.
The main point of my proposal was to avoid the mess of merging. :-)
We're going to go with the "official" procedure with the temp repo and
so for this cycle. Depending of how bumpy we find the road this time,
we may ask you again permission for letting us trying the MT export
and single changeset shortcut the next aurora dump. :-)
> Also, there's going to be a question on how many localizations really
> want to follow central on a day-to-day basis, and how many are just
> going to pick things up on aurora when the next cycle starts.
While I'm not a nightly tester myself, Guillermo tells me that there
are a number of us in es-ES living in the edge and using FX nightlies
for everyday browsing.
Ricardo
Axel Hecht
> El 31/05/11 23:31, Axel Hecht escribió:
>> I'd rather keep the mercurial trees related as the content is. There
>> might be ways to merge, drop the MT export, and then commit the merge.
>> Somewhat similar to a no-op merge as in
>> http://mercurial.selenic.com/wiki/PruningDeadBranches#No-Op_Merges,
>> just that you don't revert.
>
>
> The main point of my proposal was to avoid the mess of merging. :-)
> We're going to go with the "official" procedure with the temp repo and
> so for this cycle. Depending of how bumpy we find the road this time,
> we may ask you again permission for letting us trying the MT export
> and single changeset shortcut the next aurora dump. :-)
Think of it less of a mess and more of a tool. If you're using
consistent toolchains, any merge conflict is really an indication that
you've missed a fix in either location.
Also, a merge is sounding really awful and fuzzy, but it's a rather
clean thing to do, and it doesn't do any harm.
I'll talk more about fixes and merges in another post on MDN, I guess.
>> Also, there's going to be a question on how many localizations really
>> want to follow central on a day-to-day basis, and how many are just
>> going to pick things up on aurora when the next cycle starts.
>
>
> While I'm not a nightly tester myself, Guillermo tells me that there
> are a number of us in es-ES living in the edge and using FX nightlies
> for everyday browsing.
gtk, thanks
Axel
smo
Thanks!
Going for the jar file in the en_US or ab_CD version has been
one of my defensive steps lately. But then - at least in TB - some
smart head decided to shuffle and cut different jars (sigh) and
that was it.
Ceterum censeo we need one common en_US repository -
common to all the products. I know, I am repeating myself.
Regards
smo